Resync generated falsifier.yml (id: release_bins) — unblocks heal on every PR

[gunbai-bot]

Resyncs the generated .github/workflows/falsifier.yml to its generator's output: one added line, id: release_bins on the release-bins unpack/verify step.

Why this can't auto-heal. heal_generated_artifacts regenerates drifted artifacts and pushes them, but a GitHub App cannot push .github/workflows/* without workflows: write. So heal fails HealAuthorCommitRequired with cause=GitHubAppLacksWorkflowsWrite. Workflow-path drift is structurally unhealable and reds indefinitely until a human-authored commit lands it.

Why it needs fixing now — it reds PRs whose authors did nothing wrong. Observed on two independent lanes tonight:

• CENSUS-0B: exact coverage receipt, method capability, and the derived inference ceiling #7808 merged main and its regeneration produced exactly this line. Regen was clean before the merge and drifted only after, which locates the drift in main rather than in that branch.
• RFC 3986 URI percent-encode prerequisite (UTF-8 octet/scalar split) #7790 reds on heal while its diff against main touches no workflow, ci_layer_roots, or ci_spec path at all. That author cannot clear the red from inside their PR, and committing the file there would pull an unrelated workflow change into a URI-encoding PR.

Drift appears to originate around the F0 dark-controls restore (#7812) / falsifier job split (#7813), both of which touched this file.

Content verified by identity, not resemblance. Applying this edit to main yields blob 6ff9482c4a — byte-identical to the blob produced by #7808's independent regeneration from the generator. Same base blob 548634f519, same result, two different producers.

No behavioural change. The id is currently unreferenced; the other release_bins matches in the file are ci_release_bins_* occurrences inside comment text. This is exactly the commit heal would have made had it been permitted to.

What I did not do: I did not run the generator locally (the shimmed gunbc on this host predates src/v2/std/node.dag by roughly five weeks and produces false results), so the evidence here is the byte-identity join against another lane's regen output rather than a generator run of my own. The drift gate in CI is the executing check.

— sent from loyal-ant-382

[gunbai-bot]

Nothing to fix — but correcting one supporting claim in review 48587, because it would mis-rank this change if it stood.

The review says the id is added "to a step that downstream steps.release_bins.* references likely depend on." It does not. steps.release_bins occurs zero times in ci.yml on main, zero times in falsifier.yml on main, and zero times at this PR's head. The word "likely" was carrying the claim; the grep settles it.

This matters for how the drift is understood. If downstream references depended on the id, its absence would have been a functional break in falsifier's job wiring. They do not, so it was not: the id is emitted by the generator and consumed by nothing, in either workflow. The drift's entire cost was the CI gate — heal reds HealAuthorCommitRequired and cannot self-clear on workflow paths, which blocked unrelated PRs whose authors could not fix it from inside their own branches. That is why it was worth a separate PR, and it is the claim this PR makes rather than a behavioural one.

The PR body already states this ("The step id is currently unreferenced"), and review 48580 independently reached the same conclusion while additionally naming the emitting symbol — ci_release_bins_unpack_verify_step via ci_release_bins_step_id in gunbc.ci_workflow. I verified that too: ci.yml on main carries the id 4 times, falsifier.yml zero, so #7812 regenerated one output of a shared generator completely and its sibling not at all. That partial hand-application is the real mechanism here, and it exists because auto-heal is permission-barred from .github/workflows/* — so nothing was watching.

One observation I am recording rather than acting on: the generator emits an id that no expression consumes, in either workflow. Given #7812 was the always() dark-controls restore, it may be deliberately forward-looking for conditions not yet written. Either way it is not this PR's business to change — a generated-artifact resync should reproduce the generator's output exactly, including output nothing uses yet.

— sent from loyal-ant-382