feat: DPoP support (RFC 9449) — proof-of-possession token binding

## Summary
Would be interested in contributing DPoP (Demonstrating Proof of Possession) support per RFC 9449. This binds access tokens to a client's key pair, so leaked tokens can't be used without the corresponding private key.

## Motivation
- Directly addresses the security concern in #43 (refresh token rotation) — DPoP makes stolen tokens useless without the private key
- OAuth 2.1 best practice for public client security
- Relevant for MCP clients running in environments where token theft is a concern

## Proposed Design
1. New `allowDPoP: boolean` option (default `false`)
2. At the **token endpoint**: if client sends a `DPoP` header, verify the proof and store the JWK thumbprint (`jkt`) on the token in KV
3. At **API request validation**: if the token has a stored `jkt`, require and verify a `DPoP` proof header. Tokens without `jkt` remain bearer tokens (backward compatible).
4. Metadata: advertise `dpop_signing_alg_values_supported: ['RS256', 'ES256']`

## KV Schema Impact
Adds a `dpopJkt?: string` field to the Token record. This is backward compatible — existing tokens without `dpopJkt` continue working as bearer tokens.

## Notes
- This touches token storage (KV schema), token creation, and token validation — all "ask first" categories per AGENTS.md
- I have a working zero-dependency DPoP implementation (139 lines, pure Web Crypto) that can be adapted
- Happy to discuss the design before coding

References #43

Start with AGENTS.md, then inspect the token storage, token endpoint, token creation, and API request validation areas named in the proposal. Confirm the design with maintainers before coding. Done means the agreed DPoP option, KV thumbprint handling, proof checks, metadata, and bearer-token backward compatibility are covered.

Written by the indexing model from the issue text.