v1.5.1: bind audit publication seals to exact reviewer lanes

[jeffhuber]

Follow-up to #1023, #1025 and #1028. This is reliability work for v1.5.1.

Verified failure mode

Single-lane publication works: #1052 source run 35496105953 produced one eligible Claude reviewer seal, the default-branch publisher resolved it, posted an exact-head PASS as github-actions, emitted a receipt, transitioned labels, and satisfied the authoritative gate.

A multi-lane source run remains ambiguous: #1051 run 35494919199 completed and sealed the Claude review, but submit-staged refused with SOURCE_REVIEWER_SEAL_MISSING_OR_AMBIGUOUS while another audit lane was active in the same matrix run.

The prior hosted INTERNAL_ERROR diagnosis is retained as historical evidence, but the current reproducible problem is reviewer-seal selection across multiple lanes or seal-producing jobs.

Scope

• Bind source-seal lookup to the requested reviewer lane and exact source job/attempt identity.
• Preserve workflow name/path/event/default-ref/run-attempt/SHA, exact PR head, contributor exclusion, replay ledger, reservation, receipt, and cleanup checks.
• Emit fixed non-sensitive stage/status codes for unexpected API/response/runtime failures.
• Keep single-lane behavior unchanged.

Acceptance

• Single-lane exact-head audit publishes, receipts, transitions labels, and gates.
• Two active independent audit lanes publish their own exact seals without ambiguity or cross-lane substitution.
• A missing, duplicate within the same lane, forged, stale-head, wrong-job, or wrong-attempt seal fails closed.
• Unexpected API/response/runtime failures expose only bounded safe codes.
• Adversarial privacy and forge-resistance tests, CI, and code-mower/gate pass.

[jeffhuber]

Fresh v1.5.0 post-release evidence from PR #1051, exact head 88a9ac73070cd588015e4d14e60397b4c43665ed:

• Local-audit request run 35494915435 accepted and dispatched the current PR head.
• Source audit run 35494919199 checked out and verified the current head.
• The Claude lane completed its provider review, validated staged reviewer metadata, and completed the reviewer-seal step with a concrete digest.
• tools/audit_publication.py submit-staged then refused the source with bounded code SOURCE_REVIEWER_SEAL_MISSING_OR_AMBIGUOUS.
• A direct compatibility run against the same clean head independently returned PASS with zero P0/P1/P2/P3 findings: Docs: clarify hosted v1.5 adoption paths #1051 (comment)
• The Codex lane did not stage a verdict in the workflow run. A direct attempt correctly refused identity_matched because the PR is marked builder:codex; the gate recalculated to require only the independent Claude lane.

This is a fresh reproducible API-boundary/seal-lookup case for the issue. It is not a code-review finding and no raw provider output, credentials, source content, or local paths are included here.

[jeffhuber]

A fresh successful control narrows the audit-publication ambiguity seen on #1051.

On #1052 at exact head 1cf01ab7cbee34bb7fd1b1ffeaed3d68636e0b5a, only the Claude audit lane was requested. Source run 35496105953 produced one eligible Claude seal; the publisher resolved it, posted the exact-head PASS as github-actions, and emitted receipt seal caf8ab079d03648a2c98a996e208dba33471358a08280352a2450affe58f02d8. The publication workflow ran from default-branch SHA 3cf8860b16e596e895e89a8d4b8a985af9f140d0.

By comparison, #1051 source run 35494919199 had two active audit lanes and the Claude publisher refused with SOURCE_REVIEWER_SEAL_MISSING_OR_AMBIGUOUS despite the Claude audit itself passing.

Inference: the remaining ambiguity is likely scoped to source runs with multiple active audit lanes or multiple seal-producing steps. The repair should bind seal lookup to the requested reviewer lane/source job identity rather than require global uniqueness across the entire matrix run. The single-lane #1052 success is a useful regression control for that change.