fix(ci): a merge racing Conda Update's push leaves the run green (#1649)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

#1649. Push Changes rebases onto the tip it fetched and judged, so a merge landing between that fetch and the push had the push refused as a non-fast-forward, and the run went red. A failed push now re-fetches main (.github/workflows/cron-conda.yml:268). If main has moved to a commit without the bump in its history (:270), the step writes pushed=false, emits a ::notice (:275) and exits 0, the same way main moving before the fetch ends. The step still fails with the push's exit status in three cases: main is still at the judged tip (a declined push), the bump is already in main's history (git reported a failure but the push landed), or the re-fetch fails.

test_a_merge_landing_after_the_fetch_refuses_the_push now expects that ending and fails against the old step. Four new tests run the real step against throwaway repos: a pre-receive hook declining the push, the remote lost after the fetch, and a push that lands but reports failure, with and without a merge on top. Each one fails when its check is dropped from the step. tests/project/test_release_gates.py passes in full on 3.14 and 3.11 (119 tests).

The hunk is all inside the Push Changes run: script. No pcapkit/ file changes, so no engine's output changes.

Closes #1649

[JarryShaw]

Verdict: GOOD TO GO at fbffb0b0c. A Sonnet cross-review checked the Opus worker's change. It re-proved fail-before (the old step fails only the race test) and pass-after on 3.14, 3.11 and plain unittest, and its own mutants and adversarial races behaved. I re-ran tests/project/test_release_gates.py here: 119 passed.

It merges cleanly with main at 1024109fc and with #1657's branch; all three touch cron-conda.yml, in different hunks. Only non-blocking nits remain.

[github-actions]

Coverage: 89.68% (unit tier, Python 3.14, fbffb0b0c, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18858	954	2366	868	91.06%
pcapkit/corekit	2366	67	760	35	96.48%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	3031	152	1074	35	94.23%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17166	226	4580	190	98.07%
pcapkit/toolkit	1255	188	496	6	83.67%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4409	2342	1006	157	43.25%

Per-file detail: the coverage-html artifact of this run.