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

[zackees]

Found by zackees/ci.yml#352 (rule CACHE-034): this repository's ci.toml declared pre-prune = true on [flow.main] -- its ONLY cache writer flow -- but nothing in the repository ever runs ci-lint cache preprune (grep -rn "preprune" .github/ ci/ returns nothing). ci_lint's CACHE-004 budget arithmetic honours the declaration on its own: the lockfile-change-peak term is dropped from the worst-case footprint purely on that line, so the modelled footprint was understated by the whole peak, for free.

What changed

pre-prune = true removed from [flow.main], and the surrounding comment rewritten to record the decision instead of explaining the waiver favourably: the waiver is deliberately absent because no workflow honours it, citing zackees/ci.yml#352/#354/#360, and stating that restoring it requires a real ci-lint cache preprune step ordered ahead of the cache saves in the same run on a job holding actions: write.

Nothing else. No budget, family size, or cardinality edit. No workflow edit. No live cache entry touched.

Why (B) remove rather than (A) wire up a pre-prune step

This is fix (B) from zackees/ci.yml#354, tracked as a checklist item in zackees/ci.yml#360. Fleet precedent: zackees/bosn#533, zackees/reld#219. This repo declares the waiver on its only writer flow, so removing it brings the full lockfile-change peak back into CACHE-004's model.

CACHE-004 before vs after (from ci-lint precheck --local, repo root)

	before (waived)	after (honest)
steady total	8,619,294,720 B (8.03 GiB)	8,619,294,720 B (8.03 GiB)
+ lockfile-change peak	0 B (waived)	8,294,236,160 B (7.73 GiB)
+ [cache.pr].budget	0 B	0 B
= worst case	8,619,294,720 B (8.03 GiB)	16,913,530,880 B (15.75 GiB)
budget ([cache].budget)	10,200,547,328 B (9.50 GiB)	10,200,547,328 B (9.50 GiB)
headroom	1,581,252,608 B (1.47 GiB)	over by 6,712,983,552 B (6.25 GiB)

The honest model is over budget, so CACHE-004 now fires as a VIOLATION. That is the expected consequence of the fix, not a regression introduced by it: the waiver was masking an over-budget state. Same wall zackees/ci.yml#360 already records for soldr (soldr#3583) and running-process (running-process#1329) -- a separate budget/cardinality decision is owed there and here, and is deliberately out of scope for this PR (no budget or family numbers were changed).

Verification

uvx --from git+https://github.com/zackees/ci.yml@main ci-lint precheck --local run from the repo root, before and after the change:

• CACHE-034: 1 NEEDS REVIEW before, gone after -- cleared.
• Schema loads cleanly in both runs (no TOML/schema errors, full report + footer both times).
• Finding-count delta is exactly the two expected changes: violations 936 -> 937 (the new CACHE-004 budget breach above), needs_review 65 -> 64 (CACHE-034 gone). All 36 rule-ID headers are otherwise identical in count -- no other new findings.
• Footers: before 936 violation(s), 0 approved exception(s), 65 needs_review; after 937 violation(s), 0 approved exception(s), 64 needs_review.
• Local gate (CLAUDE.md rule 0): ci-lint local-gate run passed 45/45 checks and stamped this PR head (Local-Gate tree 944b9f80a842).