[wshlavacek]

The nightly's record mode publishes its release with the tag on the default branch's head, not on the recorded commit.

What went wrong

Record run 40899940910, at e4255465 (the merge of #1325), recorded reference-data-v3, and every suite passed. Its publish job then failed twice, on the first attempt and on a rerun, at gh release create "$tag" --target "$GITHUB_SHA":

HTTP 403: Resource not accessible by integration (https://api.github.com/repos/lanl/bngsim/releases)

Both attempts' tokens had Contents: write, the same as v2's publish job (40404704911). The job's YAML hasn't changed since v2. The repo's default workflow token is write, and no ruleset covers tags. The one difference: #1384 changed nightly-parity.yml on main at 17:53 UTC, while the recording ran, and the publish came at 20:04 UTC. A tag at e4255465 would make a ref whose workflow file differs from main's. That needs the workflows permission, which a GITHUB_TOKEN can never have. When v2 published, main's workflow files still matched its recorded commit.

That cause fits everything above, but I haven't confirmed it beyond that. The next recording that has a workflow change merge during its run will test it.

v3 was published by hand from that run's assets, tagged at main's head (05ee8039). The manifest is pinned in a separate PR.

The fix

• publish in nightly-parity.yml. gh release create --target "$DEFAULT_BRANCH" (github.event.repository.default_branch) replaces --target "$GITHUB_SHA". GitHub resolves the branch's head when it creates the tag, so the new ref's workflow files are the default branch's own.
• The notes still say "recorded by at ". They add a line saying that the tag is on the default branch's head, not on the recorded commit.
• Nothing a replay reads changes. The manifest's upstream_pin.commit is still the recorded commit (--commit "$GITHUB_SHA"), and a replay downloads each asset by URL and checks its sha256. Nothing reads what commit the tag is on.
• nightly/README.md says where the tag goes.

Evidence

• The edited step parses, with DEFAULT_BRANCH in the env and the new --target. The pinned pre-commit hooks pass. test_the_workflow_prepares_every_suite_and_plans_from_its_own_schedules reads only the prepare and pack lines, which are unchanged.
• The by-hand publish of v3 used --target main from a token without the workflow scope, and it was accepted.
• No changelog fragment: ci/changelog.py required exempts these paths.

Merging

This changes a workflow file, so it needs a maintainer's click to merge.