Fix RFC 7591 scope serialization format

[theJC]

Problem

ToolHive's dynamic client registration was sending the scope parameter as a JSON array instead of a space-delimited string, violating RFC 7591 Section 2.

This caused registration failures with OAuth providers that strictly validate RFC 7591 compliance.

Changes

• Added RequestScopeList type with custom MarshalJSON method to serialize scopes as space-delimited strings
• Updated DynamicClientRegistrationRequest.Scopes field to use RequestScopeList
• Enhanced test coverage with TestRequestScopeList_MarshalJSON to verify RFC compliance
• Updated existing tests to validate space-delimited string format
• Removed NOTE/TODO comments about the format violation
• Added INFO logging to demonstrate RFC 7591 scope marshaling in production

RFC 7591 Compliance

Per RFC 7591 Section 2:

"scope: String containing a space-separated list of scope values"

Before:

{
  "scope": ["openid", "profile", "email"]
}

After (RFC 7591 compliant):

{
  "scope": "openid profile email"
}

Real-World Testing

Tested successfully against Atlassian's Rovo MCP Server](https://support.atlassian.com/atlassian-rovo-mcp-server/docs/using-with-other-supported-mcp-clients/) and its OAuth server (https://cf.mcp.atlassian.com):

RFC 7591 Scope Marshaling Proof

RFC 7591: Marshaled RequestScopeList [openid profile email] -> "openid profile email" (space-delimited string)
Successfully registered OAuth client dynamically

This proves the fix correctly:

1. Transforms Go slice [openid profile email] to JSON string "openid profile email"
2. Sends space-delimited string per RFC 7591 Section 2 (not JSON array)
3. Successfully registers with a real third-party OAuth server

The authorization URL also confirms correct format: scope=openid+profile+email (URL-encoded space-delimited).

Testing

• All existing OAuth tests pass
• New test TestRequestScopeList_MarshalJSON validates marshaling behavior
• Updated test TestDynamicClientRegistrationRequest_ScopeSerialization verifies RFC compliance
• Linting passes with 0 issues
• Real-world validation against Atlassian MCP OAuth server

Compatibility

The response handling (ScopeList type) already supports both formats for maximum compatibility with various OAuth providers.

Question

Do any mainstream mcp servers only support non-spec / array of strings behavior? If so, does toolhive customers need a config control over the format to allow customers to force non-spec behavior?

Fixes #2596

---

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.88%. Comparing base (5177441) to head (eeeb8a6).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2597   +/-   ##
=======================================
  Coverage   55.87%   55.88%           
=======================================
  Files         311      311           
  Lines       29479    29488    +9     
=======================================
+ Hits        16471    16478    +7     
- Misses      11569    11571    +2     
  Partials     1439     1439           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.