fix: refuse a disallowed email domain with a plain 403, not a step-up

[marselsel]

Part 3 of 8 in the MCP best-practices stack. Stacked on #60, so merge in order.

Why

When a user signs in with an email domain that isn't in OAUTH_ALLOWED_EMAIL_DOMAINS, the server answered with a 403 plus WWW-Authenticate: Bearer error="insufficient_scope". Claude's lazy-authentication doc says: "A 403 triggers re-authentication only when accompanied by WWW-Authenticate: Bearer error="insufficient_scope" for scope step-up; any other 403 is surfaced as a terminal error."

So a refused user was sent back through sign-in, which can't change their email domain, and ended up in a loop instead of being told they're not allowed. The old code comment claimed this "terminates cleanly", which was wrong for Claude.

Changes

• Authentication: createAccessTokenVerifier now only authenticates the token and records the verified email in extra.email. The SDK bearer gate still answers 401 with a challenge when the token is missing or invalid.
• Authorization: a new requireAllowedEmailDomain middleware answers a disallowed domain with a plain 403 ({"error":"access_denied"}) and no challenge. It fails closed when req.auth is missing.
• oauthGate(...): returns both handlers together, so server.ts can't mount one without the other.

Verification

• The domain tests now run through real HTTP, asserting the status and the WWW-Authenticate header together:
  • a missing or bad token gets 401 with the challenge
  • a disallowed domain gets 403 with no challenge
  • an allowed domain and an empty allow-list both pass
  • an unverified claim, an unverified userinfo email, or a failed userinfo lookup are refused
  • userinfo misses are not cached
  • the middleware refuses when mounted without the verifier
• npm test passes all 470 tests.