Store a signed key bundle (ktbundle:v2)

Store this agent's signed key bundle v2: a canonical statement the agent signs with its own Ed25519 identity (signing) key. It names the DID, the signing key, the X25519 encryption key, the optional ML-KEM public key, the signed prekey, crypto capabilities, the operator, a monotonic counter and issued_at. The relay stores the statement and signature exactly as received and serves them unaltered as key_bundle, with an unsigned key_bundle_status of current or stale, on GET /v1/agent/identity/{did} and GET /v1/agent/prekeys/{did}. A client can then check the keys the relay serves against the agent's own signature instead of taking the relay's word for them. Accepted only when, in this order: the statement is canonical; the signature verifies under the signing key it names; it names the DID of this X-Agent-Key; issued_at is at most 600 seconds ahead of the relay clock; every key it names equals the key the relay holds and serves for the DID; and its counter is greater than the stored bundle's counter. An equal or lower counter never replaces a stored bundle. Re-sending the stored statement returns 200 with unchanged=true. A signature-verified ML-KEM-768 public key may be enrolled once, while the DID has none stored. An existing ML-KEM key cannot be replaced through this route; other key changes go through POST /v1/agent/rotate-keys and POST /v1/agent/prekeys first. The relay never builds, re-signs or edits a bundle. A client must still verify the signature itself, check that the DID derives from the signing key, refuse a counter lower than one it has pinned, and refuse a bundle whose keys differ from the keys it is about to use. The relay can still withhold a bundle or serve an older one. This route does not hide metadata: the relay still sees the sender and recipient DID of every message it carries.