feat: add a strict MCP 2026 authorization profile

## Problem

The provider keeps several backwards-compatible OAuth behaviors that are looser than the MCP 2026-07-28 authorization profile:

- `resource` is optional on authorization and token requests.
- Internally issued tokens without an `audience` are accepted.
- `resolveExternalToken` may authenticate a token without returning an audience.
- Client registration accepts redirect URI schemes that MCP does not allow. MCP requires HTTPS redirects except for localhost.
- OAuth endpoint options can be configured without an MCP-specific HTTPS check.

These behaviors are useful for existing non-MCP deployments and old grants, so changing the defaults would be disruptive and could invalidate stored grants or refresh tokens. However, a new MCP deployment has no single switch that prevents it from accidentally running in compatibility mode.

## Proposal

Add an opt-in MCP authorization profile, or an equivalent set of strict options, for the stable 2026-07-28 specification. The profile should fail closed when MCP requirements are not met while preserving current defaults for existing OAuth deployments.

## Acceptance criteria

- Require a valid canonical MCP `resource` during authorization and token exchange.
- Issue audience-bound access tokens for that resource.
- Reject internal tokens that cannot be shown to target the current resource.
- Require external token resolvers to return a matching audience, or another explicit proof that the token targets this resource.
- Enforce HTTPS authorization server endpoints at runtime/configuration boundaries where the final URL is known.
- Accept only HTTPS redirect URIs and HTTP loopback/localhost redirect URIs under the MCP profile.
- Keep legacy behavior available outside the MCP profile.
- Add migration notes because changing resource data stored on grants can invalidate existing refresh tokens.
- Add tests for missing resource, missing audience, wrong audience, path-aware resources, HTTPS checks, and allowed loopback redirects.

## References

- https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#resource-parameter-implementation
- https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#token-handling
- https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations#communication-security
- https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations#access-token-privilege-restriction

Start by tracing authorization and token exchange, external token resolution, client registration, and OAuth endpoint option validation. Define an opt-in MCP profile that preserves legacy defaults and covers resource, audience, HTTPS, and loopback redirect requirements. Done means the listed missing, mismatched, path-aware, HTTPS, and migration cases are covered by tests and migration notes.

Written by the indexing model from the issue text.