ci(project-status): stop a superseded sync from leaving a red check (#1066)

[JarryShaw]

Please follow the guide below

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort): not run
• make test passes, and a test case covers the change. Every tests/project module passes in its own process; the full suite was not run.
• 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?

• 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
• chore — anything else

---

Description of your pull request and other information

Closes #1066. This drops cancel-in-progress and sets queue: max. GitHub's concurrency docs say that by default a group cancels its one pending run when a newer run arrives. Under queue: max, up to 100 runs wait instead, and combining it with cancel-in-progress: true is a validation error. So simply serialising without cancelling would still leave cancelled checks after a burst of three or more events.

Freshness does not depend on run order, which the docs say is not guaranteed. Runs on one item never overlap, and each run re-reads the labels. So the last run to execute starts after every other run on that item, including the run for the final event, and its write lands last. Nightly reconcile is unchanged and still covers a run dropped because the queue was full.

TestConcurrency.test_nothing_is_cancelled pins that only group and queue: max are set. It fails against main's workflow.

UNVERIFIED: pull_request_target runs the base branch's workflow file, so this branch cannot exercise the change. It is also unverified that GitHub accepts queue: here and that no cancelled check appears after a label swap. Both show up only after merge.

[JarryShaw]

Cross-review verdict on 1f00944e1: GOOD TO GO (ran on Sonnet; author Opus)

• queue: max is documented. I checked GitHub's concurrency docs myself, and the reviewer re-checked them along with the workflow-syntax reference:
  • up to 100 runs can wait instead of being cancelled;
  • combining it with cancel-in-progress: true is a validation error;
  • ordering is FIFO but not guaranteed, which the header comment already says.
• Freshness holds. sync() re-reads the item at run time (util/project_status.py:208), and runs on one item never overlap. The last run therefore reads the final labels, whatever order the runs execute in.
• The security model is unchanged. The diff touches only comments and the concurrency: block. test_project_status gives 42 OK with PyYAML, and 42 OK with 4 skipped without it.
• The new test discriminates. test_nothing_is_cancelled fails against main's workflow. All 21 tests/project modules pass.
• Unverified until merge: pull_request_target runs main's copy of the workflow, so GitHub's acceptance of the queue key and the end of the red checks only show after this lands.

[github-actions]

Coverage: 88.74% (unit tier, Python 3.14, 1f00944e1, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18757	1035	2342	846	90.23%
pcapkit/corekit	1874	91	578	22	94.33%
pcapkit/dumpkit	136	0	40	0	100.00%
pcapkit/foundation	2422	143	842	37	92.52%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	15653	187	3942	162	98.19%
pcapkit/toolkit	487	71	144	3	84.15%
pcapkit/utilities	429	4	122	4	98.55%
pcapkit/vendor	4409	2359	1006	158	42.84%

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