feat(#575): let a deployment switch the audience floor on

[Weegy]

The piece that makes the rest reachable.

The floor and grants (#729) and all three guards (#731, #732, #733) are merged but inert — nothing installs an audience source, so every guard short-circuits. Passing audienceGrants to the orchestrator now builds a provider per turn and enforcement begins.

Why an opt-in and not a default

The floor fails closed by design. A deployment that has not yet decided who may do what would otherwise find its rooms bounded by an empty grant table — every tool refused, no context recalled, no attachment readable. So it is switched on deliberately, or not at all.

Omit the option and behaviour is unchanged, which the suite demonstrates rather than asserts: none of its 6662 tests passes one.

The chain, per evaluation

roster (ChatParticipantsProvider)
  → Principal per participant   #333 phase 1, via the same knowledge-graph
                                join `resolveTurnOwnerIdentity` uses
  → roles                       #333 phase 2
  → capabilities                #575 grants
  → the intersection            #575 floor

This module adds no policy of its own. Every failure along that chain was already made explicit by the layer that owns it — an unreadable role source yields no capability set, an unplaceable participant yields unresolved, an empty roster yields unknown — and each closes the room with a reason. It only wires.

It deliberately does not cache

The egress guard re-evaluates per tool call precisely so a participant who joins mid-turn narrows the floor before the next call fires. Memoizing the roster for a turn would make that re-evaluation theatre — the guard would keep re-asking and keep getting the turn's opening answer.

Caching is not forbidden, it is somebody else's job: ChatParticipantsProvider already documents its accessor as "expected to be cheap (cached by the implementer)". A channel adapter knows when its roster goes stale; this module does not.

A turn with no channelIdentity resolves to no principals rather than defaulting to a plausible channel kind — a wrong kind resolves against a different identity cluster, which would hand the room somebody else's grants. Refusing is the safer wrong answer.

Blast radius

Surface	Effect
Deployments that pass no audienceGrants	none
Deployments that do	the three guards begin enforcing the intersection
Published plugin contract	none
Database	none — grants come from the supplied store (InMemoryGrantStore ships; a persistent one is separate)

Verification

• Full suite: 6662 tests, 0 fail, 0 cancelled (10 new)
• 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 ✅ (unchanged — see below)
• Mutation: memoizing the provider kills both no-cache tests, including "a mid-turn joiner narrows the floor on the NEXT evaluation".

The #573 ratchet caught 10 new type errors in the new test on the first run, and they were fixed rather than baselined: the test imported the SDK through the source barrel while the provider resolves it through dist, and TypeScript treats the two as nominally different classes. Worth recording because the error message blames the assignment, not the import path.

Where #575 stands

Piece	State
ScopeId (phase 1)	merged
Floor + grants (phase 2)	merged #729
Guard 1 — egress	merged #731
Guard 2 — context recall	merged #732
Guard 3 — handle resolution	merged #733
Switching it on	this PR
Persistent (Postgres) grant store	still to come — needs an admin surface to manage grants
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.}