NS-N receipt zero: bind the Step 0 canary baseline to an executed run on main

[gunbai-bot]

The Step-0 strip-entry canary landed in #10090 with its witness pinned to the commit, tree and compiler digest of the tree it was authored against. Those literals were never the record of a run — nothing had executed the contract's own command — so the baseline a later prerequisite claim would be scored against did not exist yet.

This is that run. gunbc.namespace_step0_canary namespace_step0_canary_contract.command was executed against a clean checkout of main 20caf4eb04, and the three baseline literals in test.claim.namespace_step0_canary_witness are rebound to what it observed: that commit, its tree a6a6e0a531, and the sha256 of the target/release/gunbc built from that tree in the same dispatch. All nine witnesses in the entry pass against the rebound baseline (PASS current_main_step0_canary_receipt_is_admitted plus the eight discriminating controls).

Nothing else moved. The contract, admit_namespace_step0_canary_receipt, the subject-entry rule and the controls are untouched — exactly what the freeze note requires of a baseline correction: it lands alone. The receipt still reports Step0SubjectNotEntered blocked at ApplyTypedImportStrip; no typed source-rewrite producer exists, so the canary has not moved and this change does not claim it has. It fixes the zero against which a real move would be measured.

Two notes for whoever runs it next:

• BuildBuddy cannot execute this command. claim_batch refuses with HostBudgetUnreadable because no cgroup memory limit binds the remote runner (gunbc.host_budget_source). The run is a local or CI one.
• The digest is of an aarch64 build. A rebind from an amd64 CI runner will differ; that is a new baseline, not a contradiction of this one.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HM6r4Ydp7GCJBuaFgLBRwL