[Proposal] Define HMAC key rotation order, and whether key_id may change within a session #307

Part of issue #118. Raised in the PR #272 review. Narrower than issue #11, which covers rotation policy in general.

The problem

PR #272 says a deployment rotating its secret "configures the new secret under a new label ... so a verifier can hold both secrets while the rotation is in progress." It doesn't say:

• in what order to roll (all verifiers learn the new secret first, then signers switch, then the old one is retired), or when the old secret may be retired;
• whether a session may change key_id partway through. PR Add a Go Guardian reference implementation #169's Go Guardian binds a session to the key_id that opened it and answers a later step signed with another key with DENY key_not_bound. Other ports accept the change. The same agent behavior gets different answers depending on the Guardian.

Retiring a secret too early turns every hook into SIGNATURE_INVALID. Until issue #32 lands, that error falls to the default proceed posture, so a botched rotation quietly turns enforcement off.

Decision needed

1. Per-message or per-session key_id? If per-session, rotation only applies to new sessions, and a maximum session lifetime is needed to bound the overlap.
2. Should the spec state the three-step rotation order and the earliest safe retirement time?
3. Should SIGNATURE_INVALID for an unknown label carry data.reason (for example unknown_key_id), so an operator can tell a rotation mistake from a forged signature?

Constituencies

Guardian implementers, Observed Agent implementers, enterprise deployers.