[Proposal] Say what an Observed Agent does when a Guardian response fails verification #308

Part of issue #118. Raised in the PR #272 review. Related to issue #32, which covers the Guardian-refusal direction.

The problem

§10.3 tells Guardians what to reject. Nothing tells an Observed Agent what to do when a response fails verification: a bad signature, an unknown key_id, or a result.request_id that doesn't match the request it sent.

§6.4 counts a "malformed response" as a decision failure, and the default posture is proceed. So an on-path attacker who holds no key can flip one byte of a signed DENY, and the agent fails open. The signature turns tampering into a bypass instead of stopping it.

The reference host adapter already checks request_id correlation (GuardianResultCorrelationError in reference-implementations/agt/packages/host-adapter/src/guardian-client.ts). The spec just doesn't require it, and nothing in the reference tree verifies response signatures yet (agt README: "Nothing signs or verifies an envelope").

Decision needed

1. Should an Observed Agent MUST verify the response signature and MUST check result.request_id against the request it sent?
2. Should a response that fails either check resolve as deny (an integrity event) rather than going through the on_decision_failure posture?
3. JSON-RPC errors carry no signature in v0.1. Should the spec say an Observed Agent MUST NOT treat an error as authenticated?

Constituencies

Observed Agent implementers, platform and harness vendors, auditors and incident responders.