next-reset wipes PRs merged into next during the post-release reset window

[Shinrai]

Problem

After a next → master release squash-merges, the next-reset step force-resets next to the new master commit. A PR that merges into next in the seconds between the release merge and that reset is wiped: its merge commit disappears from next, it isn't in the release that just shipped, and it isn't in any later one. The PR still shows as merged, so nobody notices.

Three cases found on 2026-10-04 while backfilling changelogs:

• CLDMV/cldmv-node-memcache#42 (prettier 3.9.9) merged into next three minutes after the v1.1.7 release and was gone after the reset. A later PR (docs(readme): modernize for v4; drop stale v3-launch markers; fix ruleset-generator links #45) happened to re-apply the same bump.
• deps: bump @cldmv/vitest-runner from 1.2.0 to 1.5.1 in the minor group wol-proxy#30 (@cldmv/vitest-runner 1.2.0 → 1.5.1) merged seconds after a release PR and is on neither master nor next.
• deps: bump @cldmv/vitest-runner from 1.2.0 to 1.5.1 in the minor group sizeofvar#27 (the same vitest-runner bump) has the same timing and the same loss.

Related but different: #278 was the next-reset lane bug that reset next on every hotfix. This one is a race in the normal next → master path. It mostly hits Dependabot and bot auto-merges, which fire as soon as their checks pass and so often land right after a release.

Fix ideas

• Before force-resetting, compare next with the release's squash source: only reset when next's tip is the commit the release PR was built from (no extra commits). If next has moved, merge master into next (or rebase the extra commits onto master) instead of resetting.
• Or make the reset atomic against the expected tip: git push --force-with-lease=next:<release head sha>. The push is then rejected if anything landed meanwhile, and the step falls back to a merge.
• Hold auto-merge into next while a release merge is in progress (a lock or concurrency group shared with the reset).
• Whatever the fix, report any commits that would have been dropped (in the run summary, or as a comment on each affected PR) so a lost merge is never silent.

Also check other v4 consumers for the same loss: a merged PR into next whose merge commit isn't reachable from next or master.

[Shinrai]

Another case, 2026-10-04: CLDMV/configs#18 (@vitest/coverage-v8 5.0.3) and CLDMV/configs#19 (globals 17.13.0) were Dependabot auto-merges into next at 06:36 UTC, two minutes after the v1.2.3 release PR (CLDMV/configs#13) merged at 06:34. Neither is on next or master now. They were re-applied in CLDMV/configs#21. That makes five lost merges across four repos today (memcache#42, wol-proxy#30, sizeofvar#27, configs#18, configs#19). The pattern is consistent: bot auto-merges landing right after a release.

[Shinrai]

Fix in #361 (259ad07, fix/next-reset-preserve-late-merges → next).

• New action git/steps/reset-branch-after-release replaces the blind force reset for next and hotfixes. If the branch is exactly the release PR head, it is moved to the release commit as before. If PRs merged after the release PR was cut, each late first-parent commit is replayed onto the release commit (flattened, with its (#N) subject kept, signed by GitHub for the bot App through the Git Data API). Each one is listed in the run summary and commented on its PR. If a replay conflicts, the branch is left untouched, the job fails, an issue is opened and the affected PRs get comments. Nothing is dropped silently.
• Ref updates are a compare-and-swap against the tip the plan was built from: GraphQL updateRefs with beforeOid first, then git push --force-with-lease=refs/heads/<branch>:<sha>. If the branch moved, the step re-plans instead of overwriting. A guarded REST force update, followed by a merged-PR audit, runs only if both CAS paths are refused with the branch unmoved.
• Timing: wait-for-tags now runs only in CLDMV/.github. In consumers it polled the repo's own v<major> tag, which is unrelated to the @v4 actions they use. It always waited the full 2 minutes where no such tag exists, and that is the window in which these merges landed. Consumers now sync immediately after the release commit.
• Not done: holding bot auto-merge during a release. Dependabot and member auto-merge use GitHub's native server-side auto-merge, which no workflow concurrency group can pause. The carry-forward covers that window instead. This is documented in release-flow-v4.md.
• Still open from the issue: sweeping the other v4 consumers for merged PRs into next whose merge commit is on neither next nor master.

[cldmv-bot]

Closed in v4.30.7 — resolved by #361.