ci: stop cancelling main runs, and cover hybrid prompt-cache checkpoint resume

[solderzzc]

Two CI follow-ups coming out of #212, kept in separate commits.

1. fix(ci): stop cancelling in-flight CI runs on main

cancel-in-progress: true applies to every ref, so rapid successive merges to main killed the older run mid-flight. GitHub reports a run whose jobs were cancelled as failure, so main collected red conclusions with no test having failed — and Release, which fires on workflow_run: completed and only publishes when CI concluded success, skipped those commits entirely.

Concretely, on 2026-10-05: 0669d38d was cancelled with 13 jobs cancelled, b1e8ad1d was cancelled 9 seconds after starting, and 8469a174 ended failure with 11 jobs green and 3 integration_matrix jobs cancelled. The three Release runs for those shas are all skipped.

Cancel superseded runs on pull requests only. main is the release baseline — each merged commit should be allowed to finish.

-  cancel-in-progress: true
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

A bare false would not work here: it is a truthy string. The expression is what evaluates to a boolean, which is why the comment in the file spells that out.

2. test(ci): cover hybrid prompt-cache checkpoint resume end to end

#212 lets a hybrid prompt that diverges from a cached one resume from a recurrent-state checkpoint instead of re-prefilling from zero. The unit suite (HybridCacheCheckpointTests) exercises that bookkeeping against synthetic caches. Nothing covered the claim that actually matters on a real model — that a checkpoint resume computes the same thing as a full prefill — which is the failure that would go unnoticed. tests/test-server.sh Test 26 only checks identical-prefix reuse, which never enters the checkpoint branch.

tests/test-hybrid-cache.sh decodes the same diverged prompt twice: once on a server warmed with the unedited prompt (checkpoint resume), once on a freshly started server (full prefill), and requires byte-identical greedy output. It also asserts the checkpoint branch was taken and supplied a worthwhile span, so a silent fallback to a full prefill fails the test rather than passing it.

Registered as an integration_matrix entry on mlx-community/Qwen3.5-0.8B-MLX-4bit — a hybrid (GatedDeltaNet + attention) checkpoint already in use by the speculative-decoding job, so the download is one the CI cache knows about.

Why the prompt is three turns

The first version of this script used two ~1500-token turns and failed as written, reusing 48 of 3148 tokens: with minGap 2048 the only checkpoint that survives is the anchor immediately before the divergence. Three turns put a checkpoint far enough ahead of the edit to skip a real span. That is worth knowing for anyone reading the log line, since the reuse ratio is a function of turn spacing rather than a constant.

Verification

Run locally against both build configurations, using the same invocation as CI (tests/test-<modality>.sh .build/release/SwiftLM 15413):

Check	Result
debug binary	6/6 pass, exit 0
release binary	6/6 pass, exit 0
checkpoint reuse	HIT (hybrid): 3141/4708 tokens reused (checkpoint of 4689)
resumed vs full prefill	byte-identical greedy output (OK3)
mutation	blanking the log lookup makes the run fail (exit 1) on the checkpoint assertion

The mutation check matters: it is what shows the test goes red when the feature does, instead of passing vacuously.

ci.yml parses, the matrix resolves to 10 entries, bash -n is clean and the script keeps its executable bit.

No production code is touched by either commit.