[nikolas-sapa]

Summary

Closes #3723.

This PR aligns the error responses returned by the built-in authorization server on /token and /revoke with RFC 6749 §5.2 and RFC 7009 §2.2.1:

1. /token with grant supported by server but unauthorized for client: returns error="unauthorized_client" instead of unsupported_grant_type (RFC 6749 §5.2: "The authenticated client is not authorized to use this authorization grant type").
2. /token with grant unsupported by server (e.g. client_credentials, password, unknown): returns error="unsupported_grant_type" instead of failing Pydantic union validation with invalid_request (RFC 6749 §5.2: "The authorization grant type is not supported by the authorization server").
3. /revoke with client authentication failure: returns error="invalid_client" instead of unauthorized_client (RFC 7009 §2.2.1 / RFC 6749 §5.2). Added invalid_client and unsupported_token_type to RevocationErrorResponse.
4. WWW-Authenticate header on HTTP 401: when a client attempts to authenticate via Authorization: Basic ... on /token or /revoke and authentication fails, the response now includes WWW-Authenticate: Basic realm="OAuth" per RFC 6749 §5.2.

Test Plan

• Added 4 regression tests to tests/server/auth/test_error_handling.py covering all four cases (verified failing RED on base, passing GREEN on fix).
• Updated existing assertion in tests/server/auth/test_identity_assertion.py testing unauthorized client registration.
• Ran full test suite across tests/server/auth and tests/interaction/auth: 176 passed.
• ruff check and ruff format --check: clean.
• pyright: 0 errors, 0 warnings.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3723.

If a maintainer assigns you to #3723, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.