[Proposal] Bind an HMAC key_id to the agent_id it may sign for #306

Part of issue #118. Raised in the PR #272 review.

The problem

PR #272 defines HMAC key_id as "an opaque label, chosen by the deployment, that names one configured secret", and a verifier rejects an unknown one. Nothing ties a key_id to metadata.agent_id.

In a deployment where several agents share one secret (the simplest setup, and the one most people will copy), any agent can sign a request claiming to be any other agent_id. It can also derive another agent's session key from a session_id, which appears in traces. Per-agent policy keyed on agent_id is then a claim, not an authenticated identity.

Issue #11 covers key distribution and revocation more broadly. This issue is only the binding question.

Decision needed

1. Should a Guardian resolve key_id only among the secrets configured for the request's agent_id (and tenant_id when present), treating any other as unknown?
2. Should the spec RECOMMEND one secret per agent, and say plainly that under a shared secret agent_id is unauthenticated?
3. Should agent_id go into the HKDF info too? That would change the derivation PR Fix the HMAC key derivation, define key_id, and record an unresolved request_id_ref #272 just pinned, so it needs to be decided before more implementations ship.

Constituencies

Guardian implementers, enterprise deployers, policy authors.