Add Signal batch trust policy gate

README.md

@@ -44,6 +44,7 @@ make install-local
 - `step.signal_trust_reset` - replace a stored trust record after caller-approved key rotation, with reason refs and optional previous-record compare-and-set.
 - `step.signal_trust_history` - query bounded, redacted trust decision history for app audit/support flows without returning raw safety-number evidence.
 - `step.signal_trust_policy_check` - gate app send/fanout/transport steps on stored trust record, last trust event status, record CAS, and freshness policy.
+- `step.signal_trust_policy_check_batch` - gate room send, fanout, collaboration, and queue workflows across multiple trust refs with one aggregated fail-closed decision.
 - `step.signal_account_keys` - derive account entropy, SVR, backup, backup-id, and PIN hash keys.
 - `step.signal_username_artifact_prepare` - generate upstream-compatible username reservation hash artifacts and optional encrypted username-link payloads without creating username proofs.
 - `step.signal_username_link_create` - create an encrypted Signal username link payload.
@@ -148,15 +149,18 @@ outputs contain refs, statuses, policy, reason refs, and timestamps only; they
 do not return raw display safety numbers, scannable fingerprints, identity key
 bytes, private keys, plaintext, ciphertext, service credentials, or auth
 headers. Unknown history cursors fail closed instead of looking like end of
-history. `step.signal_trust_policy_check` reads the stored trust record and the
+history. `step.signal_trust_policy_check` reads one stored trust record and the
 latest redacted trust event before an app proceeds to send, seal, fan out,
-queue, or transport encrypted data. It can enforce required record refs,
-allowed last statuses, max observed age, and explicit legacy-record opt-in.
-Denied policy checks fail closed by default; `report_only` returns denial
-metadata for audit/routing flows without running downstream send steps. This is
-a stored-state gate, not fresh key verification: apps should still run
-`step.signal_trust_observe` with current identity evidence before policy checks
-when they need to detect key changes. These primitives store public trust
+queue, or transport encrypted data. `step.signal_trust_policy_check_batch`
+applies the same decision rules to multiple trust refs and returns redacted per
+recipient decisions plus aggregate allowed/denied counts and a batch policy ref.
+These gates can enforce required record refs, allowed last statuses, max
+observed age, and explicit legacy-record opt-in. Denied policy checks fail
+closed by default; `report_only` returns denial metadata for audit/routing
+flows without running downstream send steps. This is a stored-state gate, not
+fresh key verification: apps should still run `step.signal_trust_observe` with
+current identity evidence before policy checks when they need to detect key
+changes. These primitives store public trust
 evidence and refs only; they do not contact the official Signal service, link
 devices, register accounts, send or receive service messages, or interact with
 the official Signal app.