WorkOS AuthKit now supports RFC 8707 Resource Indicators — developers configure allowed MCP resource URLs in the Dashboard and AuthKit mints tokens with a matching aud claim. That replaces the old client_id-as-audience approximation, which was a weak stand-in that never actually bound tokens to a specific server. The scary warning about token replay risk in the AuthKit docs is no longer true; this PR removes it and makes FastMCP's side of the integration match.

The ergonomic shape matters. Users already pass base_url, and FastMCP already computes the server's canonical resource URL from it (base_url + mcp_path). That same URL is what AuthKit needs in the Dashboard, what gets advertised in .well-known/oauth-protected-resource, and what should be validated as aud. So there's no new parameter — AuthKitProvider auto-binds JWTVerifier.audience in set_mcp_path using the URL it already knows. On startup the server logs the exact string to paste into the Dashboard's "MCP resource indicators" list. One manual action; compliance follows.

# This is the whole integration. No client_id, no audience kwarg.
auth = AuthKitProvider(
    authkit_domain="https://your-app.authkit.app",
    base_url="https://your-server.com",
)
mcp = FastMCP("My App", auth=auth)
# Server logs: "AuthKit tokens will be validated against aud=https://your-server.com/mcp.
#               Configure this URL as a Resource Indicator in the WorkOS Dashboard."

Two supporting changes were needed to make this clean. RemoteAuthProvider.get_routes didn't previously invoke set_mcp_path, which meant subclass lifecycle hooks never fired outside the full OAuth-authorization-server code path — fixed by moving that call into the base. And the JWT verifier's rejection-reason logs (issuer/audience/scopes mismatch) were at DEBUG level, so the generic "Bearer token rejected" was the only signal a user normally saw; those are now WARNING, which would have immediately surfaced the audience mismatch we hit while testing this against a real AuthKit domain.

Also folded in some housekeeping while touching the auth examples: renamed examples/auth/authkit_dcr to examples/auth/authkit (DCR vs CIMD is a Dashboard choice, not an example-level distinction), rewrote the README around the Dashboard setup, and normalized every auth example to use 127.0.0.1 consistently across server/client/README so future RFC 8707 providers don't hit the localhost/127.0.0.1 audience mismatch that bit us during testing.

Breaking: client_id is removed from AuthKitProvider. Callers relying on it should either (a) configure Resource Indicators in the Dashboard and let the provider auto-bind the audience, or (b) pass an explicit token_verifier with their chosen audience — the provider respects user-supplied verifiers and doesn't touch them.