Map negative-path test coverage against the release attack checklist

[jeremi]

Part of the 1.0 release-readiness push (see release/READINESS.md).

Blocked on: the attack checklist derived from the Relay and Notary threat models (maintainer work, in progress). Do not start until the checklist is committed and linked here.

Context

The workspace has a large test suite, but coverage of denial paths (requests that must be rejected) has not been mapped systematically. Examples of the checklist's attack classes: algorithm confusion, audience confusion, replay, expired or not-yet-valid tokens, scope escalation, injection through connector queries.

Scope

For each checklist item, record either the existing test(s) covering it (file and test name) or mark it as a gap. Then close the gaps: each new test must assert both that the request is rejected and that the audit record for the rejection is correct.

Acceptance

• Mapping committed (checklist item to test reference or gap).
• Every gap has a test PR linked, or an explicit maintainer-approved deferral with rationale.
• New tests assert denial and audit-record correctness, not just non-success.

Security note

If this work surfaces a suspected vulnerability, report it per SECURITY.md; do not post details on this issue.

[jeremi]

The negative-path mapping is unblocked: the internal checklist has been consolidated at registry-internal/docs/security-reviews/negative-path-checklist.md. Keeping the public thread detail-neutral per the security-review split; this issue can proceed as test coverage and route-matrix hygiene against that internal artifact.

[jeremi]

Unblocking note: the attack checklist this maps against is complete (maintainer-side artifact, merged 2026-07-06). Coverage mapping can start; the checklist itself stays internal, per the standing rule that adversarial detail does not go on public issues.

[jeremi]

Sequencing note from the 2026-07-07 decisions: #314 replaces the config-apply and break-glass approval surfaces with signed bundles verified at boot plus a local override file, and its acceptance includes tamper and rollback matrices for the new surface. Map the config-trust portion of the checklist against the post-#314 surface, or re-run that section after it lands, so the mapping does not certify routes that are about to be deleted.