(11/n) auth follow-up coverage and resource defaulting

[philipnee]

Why

This follow-up locks down the auth behavior introduced by the client policy and client identity work, and fixes a client-compatibility issue where some OAuth clients omit the optional resource parameter on / authorize.

What changed

• Default missing /authorize resource values to the instance's canonical /mcp resource before validation, logging, and auth-code issuance.
• Preserve audience binding by issuing authorization codes with the canonical resource.
• Keep explicit wrong resources rejected with error=invalid_target.
• Add resource_defaulted=true|false to authorize request-log details.
• Add server-level coverage for:
  • missing-resource GET and POST authorize flows
  • explicit resource mismatch redirects
  • unknown OAuth clients rejected as quarantined once clients[] is configured
  • session token rejected on /mcp once clients[] is configured
  • legacy session-token access when clients[] is absent
• Add a CHANGELOG note for the OAuth client-compatibility fix.

How

/authorize now applies a canonical resource default immediately after parsing request parameters. That defaulted value flows through validation, request logging, rendered approval forms, and
oauth.issueCode(...), so the resulting access token remains audience-bound to the current mvmt /mcp resource.

The new tests exercise the behavior through the HTTP server rather than only the OAuth store, so auth middleware behavior and redirect responses are covered together.

Changed files

src/server/index.ts - default missing authorize resources and log whether the default path was used.

tests/server.test.ts - add server-level coverage for resource defaulting, explicit resource mismatch, quarantined OAuth clients, session-token rejection with clients[], and legacy session access.

CHANGELOG.md - document the OAuth client-compatibility change.

Verification

npm test -- tests/server.test.ts tests/oauth.test.ts
npm run verify