bug: propagate OAuth scopes in successful DCR MCP flows

[aheritier]

Problem

Docker Agent's Atlassian Jira/Confluence MCP authv2 path-specific Protected Resource Metadata (PRM) discovery can return the required OAuth scopes, but successful Dynamic Client Registration (DCR) flows pass nil scopes both to DCR and to the subsequent authorization request.

This causes Atlassian authentication to complete with 401/insufficient-permissions failures. It also affects scope-only configurations where clientId is optional. The defect has been latent since the initial DCR flow; it is not a known July runtime regression.

Other providers may mask the defect through provider defaults, pre-registered clients, or client-driven flows.

Expected behavior

• Configured scopes take priority.
• Otherwise, use the scope challenge when available, then PRM scopes for successful DCR flows.
• Explicit-client/pre-registered behavior remains unchanged.
• After the fix, previously issued tokens must be removed and the user must complete fresh consent before retesting.

Reproduction

1. Use a disposable Docker Agent configuration for an Atlassian Jira or Confluence MCP server with authv2 enabled, no secrets committed, and scopes omitted from the client configuration; leave clientId optional so DCR is used.
2. Start authentication against a test Atlassian tenant and capture only safe debug/request metadata (URLs, scope values, and status codes); do not share client secrets, authorization codes, refresh tokens, or access tokens.
3. Confirm PRM discovery returns path-specific scopes.
4. Complete DCR and authorization, then invoke an MCP operation requiring the discovered permission. Observe that the authorization/DCR requests did not carry the discovered scopes and the operation fails with 401 or insufficient permissions.
5. Remove the existing local tokens, repeat authentication, and provide fresh consent when validating the fix.

Acceptance criteria

• A configured scope list is propagated unchanged and takes precedence over discovered scopes.
• When scopes are not configured, successful DCR uses the scope challenge if present, otherwise the path-specific PRM scopes, for both DCR and authorization.
• Explicit-client and pre-registered-client flows retain their existing behavior.
• Scope-only configuration with optional clientId successfully authenticates Atlassian Jira/Confluence MCP authv2 and permits an operation covered by the granted scope.
• Tests cover configured-scope precedence, challenge fallback, PRM fallback on successful DCR, and explicit/pre-registered behavior.
• Tests verify no sensitive credentials or tokens are logged or required in fixtures.
• Tests assert the exact scope values sent in both DCR registration and the /authorize request, including the empty-challenge plus PRM fallback path.

Field evidence (sanitized)

1. A successful DCR authorization request omits scope.
2. The issued token receives the default *:agent-interface scope family, while public PRM metadata lists granular Jira/Confluence scopes; calls made with the scoped permissions return a generic 401 ... scope does not match response.
3. A second MCP client using the scopes advertised by PRM succeeds against the same endpoint, making requested-scope selection the differentiator.
4. Reproduction with fresh consent rules out a stale token, and a completed flow rules out callback/redirect handling. Standard scope propagation is sufficient; no audience, prompt, or provider-specific behavior is needed.
5. Provider guidance, paraphrased: scopes need to appear in /authorize, and fresh consent plus a fresh token is required.
6. Acceptance criterion added above: assert exact scope values in both DCR registration and /authorize, including the empty-challenge plus PRM fallback path.

Follow-up note

Repeated OAuth runs that register fresh DCR clients may warrant registration reuse.