- Separate "Implementation requirements" (MUST verify ES256) from
    "Usage guidance" (SHOULD use ES256 for compatibility)
  - Removed "Signers: use newest key" - no way to determine key age
    from JWK spec, and verifiers accept any key in signing_keys[]

  This restructures UCP's signature specification based on working group
  discussion. Key changes:

  Multiple authentication mechanisms:
  - HTTP Message Signatures, API keys, OAuth 2.0, mTLS, choose whichever
  - Businesses choose what fits their security model and integration patterns
  - Implementations SHOULD maintain allowlists of trusted profiles

  RFC 9421 for all HTTP transports:
  - REST and MCP (streamable HTTP) now use the same signing mechanism
  - Signature + Signature-Input headers replace the deprecated Request-Signature
  - Covered components: @method, @path, content-digest, ucp-agent, idempotency-key

  Content-Digest (raw bytes) replaces JCS canonicalization:
  - Request signatures hash raw body bytes per RFC 9530
  - Simpler implementation, no JSON canonicalization complexity
  - JCS retained only for AP2 mandates

  RFC 9421 (HTTP Message Signatures) deliberately leaves key discovery to
  the application: "a means of retrieving the key material... is within
  the purview of the application and outside the scope of this
  specification." UCP fills this gap.

  UCP profiles serve dual purpose — they declare capabilities for
  negotiation and publish signing keys for identity verification. This
  means the same fetch that enables capability negotiation also resolves
  the signing keys needed for RFC 9421 signature verification. The new
  Identity & Authentication section in overview.md defines this protocol:

  Key Discovery: profile URL -> fetch -> match keyid to kid in
  signing_keys[] -> verify signature. Both directions use the same
  mechanism (businesses at .well-known/ucp, platforms via UCP-Agent
  header).

  Profile Hosting: HTTPS-only, no redirects, Cache-Control with public
  and max-age >= 60s. Profiles are stable identity documents, not
  per-request configuration.

  Profile Fetching: two-tier trust model — a registry of pre-approved
  platforms with cached identity, and dynamic profile discovery for
  unrecognized platforms bounded by a fixed discovery footprint (LRU
  cache, global rate limit, backoff, async 503+Retry-After).

  Also defines authentication mechanism compatibility (API keys, OAuth,
  mTLS, HTTP Message Signatures) and identity binding requirements
  (authenticated identity must match UCP-Agent header).

  Slims signatures.md to signing/verification mechanics only; removes
  Profile Trust Model section (replaced by normative requirements in
  overview.md). Fixes orphaned validate_profile_url() reference, aligns
  error terminology with registry concept, and scopes the .well-known/ucp
  path constraint to business profiles only.