ci: drop the unhonoured pre-prune waiver (CACHE-034)

[zackees]

Closes #3678

What

ci.toml declared pre-prune = true on both writer flows (main and nightly).
Nothing in this repository has ever run ci-lint cache preprune -- verified by
grep -rn "preprune" .github/ ci/, which returns nothing.

CACHE-004's budget arithmetic honoured the declaration on its own: with every
writer flow pre-pruning, the lockfile-change peak term is dropped from the
worst-case footprint. This repository's modelled footprint was understated by
exactly that term -- 17.30GB -- for free.

This PR takes fix (B): it removes the declaration so the arithmetic counts the
peak honestly. It does not touch [cache].budget, any family size, or any live
cache entry.

CACHE-004 was already failing

The most important thing in this PR is that CACHE-004 is a violation both
before and after. Before this change the worst case was already 19.87GB against
a 9GB budget. The pre-prune declaration was not what made it pass, and nothing
here was resized, rebudgeted, or otherwise adjusted to make it pass.

The honest statement is that this repository's declared cache shape does not fit
a 9GB budget, and the waiver was hiding 17.30GB of that. The declared shape:

• compile alone: 2600MB x 6 platforms = 16.36GB
• dylint-out (lockfile-keyed): 700MB = 0.73GB
• registry (lockfile-keyed): 200MB = 0.20GB
• [cache.pr].budget: 1.00GB on top of the above

No combination of pre-prune and the current family sizes fits 9GB. Making this
pass honestly requires a real decision about which platforms write a compile
entry and what each one actually weighs -- a measurement and cardinality
question, not a ci.toml edit. I have deliberately left that visible rather than
picking numbers to make it green. Raising [cache].budget is not an option:
9GB is already the fleet's floor near GitHub's 10GiB repository cap, and this
repository's live caches were measured at that ceiling.

Why not (A)

ci-pre.yml is the closest fit -- it already holds actions: write and runs
first -- but nothing in ci.yml needs: it. It is invoked as a job and
deliberately un-gated so that a janitor sweep never delays a build (its own
header comment says so). A pre-prune step placed there would not be ordered ahead
of this repository's setup-soldr saves in the same run, so it would not remove
the peak it is supposed to remove. Ordering it correctly means making build jobs
depend on a cache-maintenance job, which inverts the deliberate design and slows
every run. That is a larger change than this honesty fix should make, and it
would not fix the underlying over-budget shape anyway.

CACHE-004 arithmetic, before and after

Verified with
uvx --from "git+https://github.com/zackees/ci.yml@92106df315bd28de24ef1808c893c91a5859122d" ci-lint precheck --repo . --local

	before	after
steady total	18,800,967,680 B	18,800,967,680 B
+ lockfile-change peak	17,301,504,000 B (waived)	17,301,504,000 B (counted)
+ [cache.pr].budget	1,073,741,824 B	1,073,741,824 B
worst case	19,874,709,504 B	37,176,213,504 B
budget	9,663,676,416 B	9,663,676,416 B
CACHE-004	VIOLATION	VIOLATION

Total precheck findings are unchanged at 1806 violations / 26 needs_review before
and after, confirming this edit introduces no new finding -- it only changes the
number the existing CACHE-004 finding is about.

GATE-005

No test step was added. This change touches ci.toml only -- no workflow, no
test invocation, no runner. The isolated-runner requirement for this repository's
test suite is untouched.

Unresolved

• CACHE-004 remains a live violation and needs a sizing decision (which platforms
  write compile, and each platform's real weight). Not resolvable by editing
  ci.toml honestly.
• Restoring pre-prune = true honestly needs a pre-prune step genuinely ordered
  ahead of the saves, which the current ci-pre.yml call structure cannot
  express.
• No Local-Gate: trailer is attached. The precheck was run and is reported
  above; I did not fabricate a gate attestation.

[zackees]

CACHE-034 is implemented and merged — zackees/ci.yml#352 (docs #353). It fires on soldr's main today, so this PR is the remediation for an enforced rule rather than a review suggestion.

Verified independently

Your headline claim is correct and is the important part: CACHE-004 was already a VIOLATION before this change. Confirmed against main — compile is declared max = "2600MB" with per = "platform" across 6 platforms = 15.6 GB steady against a 9 GB budget, before any peak term. The pre-prune waiver was not what made it pass.

Leaving it failing rather than resizing families is the right call, and matches how this was handled on zackees/clud#1800 — a repo that honestly fails its own check is correct; one with numbers invented to pass is not.

Why the two repos came out differently

Worth recording, since three of the six affected repos have now been checked and the answer is not uniform:

repo	steady	honest worst	budget	verdict
bosn	3.36 GB	7.27 GiB	9 GB	fits
running-process	11.04 GB	19.19 GiB	9 GB	already failing
soldr	18.80 GB	34.6 GiB	9 GB	already failing

bosn's honest number still fits, so removing its waiver is a pure correction. soldr's shape is 2× over budget on its own — that is a cardinality/max measurement decision, and it is not solvable by any pre-prune edit.

Your point about ci-pre.yml holding actions: write but not being needs:-ordered first is the crux: ordering it correctly would invert that file's deliberate design ("a janitor never delays a build") on every run, without fixing an over-budget shape. Correct to decline.

GATE-005 untouched and correctly so — ci.toml only.

[zackees]

One correction to my earlier framing, in the interest of not sending you after a dead end: I said adding the pre-prune step was "the smaller diff". For soldr that option is not currently expressible, and the reason is the one you correctly identified — ci-pre.yml holds actions: write but nothing needs: it, deliberately, so a janitor never delays a build. Wiring it in would invert that design on every run, and would not fix the over-budget shape regardless.

Filed the shared prerequisite as zackees/ci.yml#354, covering the three repos that hit this: soldr, bosn and running-process. It records that no repository can currently place a pre-prune ahead of its cache saves, and that this is a per-repository owner decision rather than something ci-lint should absorb.

This does not change the recommendation. soldr's real problem is not the waiver — compile is 15.6 GB steady against a 9 GB budget, so CACHE-004 fails with or without it. Removing the fiction makes an existing failure legible; it does not make it go away. The cardinality/max decision is the actual work, and this PR is the smaller half of it.

[zackees]

The dead pin is fixed on this branch — e19d4b4 repoints linter at 0fcff997 (carries CACHE-034). See soldr#3584.

Verified with CT-007, the rule written for exactly this and merged as zackees/ci.yml#355: ci-lint audit --repo . now reports 0 CT-007 findings against this tree, where before it reported the 422. So the fix is confirmed by the enforcement mechanism rather than by inspection.

GATE-005 isolation is untouched — [gate.isolation] in local-gate.toml keeps its bosn runner, SOLDR_TEST_ISOLATED marker, nextest guard, and proves-tree (GATE-009).

Still not stampable — the host, not this change

local-gate run no longer fails at pin resolution, but it cannot start:

bosn: refusing to mint a new registry identity.
/tmp/bosn-soldr-pp/registry.sqlite3 is missing, but 15 Docker object(s)
already carry a Bosn registry label, so this machine is not a clean
first run.

That is the standing host-hygiene gap in zackees/ci.yml#322 — the same blocker bosn hit. bosn declines rather than mint a new identity that would orphan every labelled object, which is the correct conservative behaviour. Reclaiming them is a destructive operation on someone's machine and is the owner's call.

What this branch now contains

1. e19d4b4 — repoint a pin that has never existed, which was making the gate unrunnable and GATE-003 fail on every PR.
2. 04b008f — remove the unhonoured pre-prune waiver.

Worth restating the finding from the original review, since it is the substantive one and neither commit addresses it: soldr's CACHE-004 was already failing before either change. compile is declared max = "2600MB" with per = "platform" across 6 platforms = 15.6 GB steady against a 9 GB budget — over budget before any peak term. The waiver was not what made it pass. That needs a cardinality/max decision, the same wall zackees/clud#1800 hit.

Holding as a draft for the host reason alone. If you would rather land (1) on its own — it is what unblocks this repository's gate and precheck, independent of the cache question — say the word and I will split it out.

[zackees]

Cross-reference: this PR's linter-pin repoint (a07bab94 → 0fcff997) is the core fix for #3584 (verified: the new SHA resolves). Merging this should close it — consider adding Fixes #3584 to the body. The other half of #3584 (making "must resolve" a violation rather than needs_review) lives in zackees/ci.yml's checker and stays open there. The [cache.family] sizing half of the audit is tracked separately in #3580, which will be edited to avoid conflicting with this PR's ci.toml hunks.