feat(authorization): send the RFC 8707 resource parameter

[tylerklose]

Fixes #465.

The runner is the MCP client in the authorization direction. The spec requires
clients to send resource in both the authorization request and the token
request. It sent neither.

Changes

• src/index.ts — --resource <uri> on the authorization command.
• src/schemas.ts — resource on AuthorizationServerOptionsSchema, so
  --file supplies it too.
• authorization-code-grant.ts — sends resource in the authorization request
  and the token request when it's set.

The value must be an absolute URI with no fragment — the spec's own two invalid
examples are mcp.example.com (no scheme) and https://mcp.example.com#fragment.

Two conditionals, one per request. It's only sent when the flag or file field is
present, so existing runs are unchanged.

No new check IDs

Deliberate. Here the runner is the client, so a check for "the runner sent
resource" is the harness grading its own homework — it can never fail. URI
validation happens in the schema, before scenarios run, so a check for that can't
fail either.

None is needed. The existing grant checks now reach a path they couldn't before:
an AS that mishandles resource fails them, where before it was never asked.

Tests

Six cases added (npm test: 530 passing).

Scenario:

• resource appears in both the authorization URL and the token body when set
• it appears in neither when unset — guards against it silently becoming
  unconditional
• a mock authorization server that rejects resource makes the existing grant
  check fail, and passes when the parameter is absent

Schema:

• accepts an absolute URI
• rejects a fragment
• rejects a relative URI

Revert the two conditionals and the first and third fail.

Validated against a real authorization server

Run against hitch-rails, my own Rails MCP server and its own authorization
server. It requires resource at both endpoints, and rejects a
token exchange whose resource doesn't match the one recorded at authorization
time. The public-client grant passes end to end — it couldn't have before this
change, because the parameter never arrived.

The confidential-client path wasn't exercised: selectTokenAuthMethod returns
none whenever an AS advertises none, even with a client secret supplied, so
the runner shows up as a public client against a client registered for
client_secret_basic. Unrelated to this change; worth raising separately.

Open question

See the issue: a run without --resource stays silent about the requirement.
Whether it should fail instead, or report untestable at WARNING per #248, is your
call.

Checklist

• npm run build passes
• npm test passes (530)
• eslint + prettier clean
• No scenario added or removed; no check IDs changed, so no traceability drift
• Run against a real authorization server (above)