feat(#575): wire the audience floor's handle-resolution guard

[Weegy]

The floor's third and last guard (spec §5.2), completing the trio after #731 (egress) and #732 (context recall).

A storage key is a handle: minted in one turn, redeemable later, and — being just a string — pasteable into a different room.

The check rides with the handle, not with the call sites

The spec says the check "must ride with" the handle because it outlives the turn. Adding a call at every resolution site works exactly until somebody adds the next site and forgets. So enforcement lives in a wrapper around AttachmentReader, applied at its single construction site. read_attachment, ingestAttachments and anything added next are covered by construction.

This closes a path guard 1 did not

read_attachment is a tool, so it already passed dispatchTool. But ingestAttachments resolves storage keys straight off the inbound turn, with no tool call in sight — and that is the path a caller actually controls. Guarding only the tool would have left it open while looking complete.

Why a refusal looks like "unknown key"

A refusal returns undefined, the reader's existing "unavailable" contract, so no caller needs new error handling. That makes a denial indistinguishable from a missing key to the caller — deliberate, not sloppy: a message confirming the key exists but is off-limits would leak the document's existence to a room that may not know it. The reason goes to the operator log, where it is actionable and not a side channel.

The inner reader is never reached on a refusal, so a denied redemption does not even touch the store — a store hit is itself observable.

Redeeming a handle and invoking the read tool are separate capabilities; neither grants the other.

Remaining gap — named, not assumed closed

This checks the floor at redemption, not at minting. It stops a room from redeeming a handle that room may not read, but cannot yet stop a handle minted in a narrow room from being redeemed in a wider one that happens to hold the capability. Binding the minting audience to the handle needs the attachment store to persist it, and that store lives in the channel plugins rather than here.

Blast radius

Surface	Effect
Deployments without an audience source	none
Deployments with one	attachment redemption is refused when the room may not jointly read stored attachments
Published plugin contract	none
Database	none

Verification

• Full suite: 6652 tests, 0 fail, 0 cancelled (8 new). None installs an audience provider — the evidence for the inertness claim.
• npm run typecheck ✅ · npm run lint ✅ · Epic: Integrated dev platform — isolated per-job runners that clone, develop, test, and ship PRs #470 ratchet 3294 ✅ · npm run typecheck never typechecks middleware/test/ #573 ratchet 406/406 ✅
• Mutation: removing the guard from readByStorageKey kills three tests — "both methods are guarded", "indistinguishable from unknown key", and "the inner reader is never even reached".

Where #575 stands after this

Piece	State
ScopeId (phase 1)	merged
Audience floor + grants (phase 2)	merged, #729
Guard 1 — egress	merged, #731
Guard 2 — context recall	merged, #732
Guard 3 — handle resolution	this PR
Persistent grant store	still to come
Handle bound at minting	needs channel-plugin storage

Refs #575

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}