ci: declare the cache model main actually writes (zackees/ci.yml#93)

[zackees]

Closes zackees/ci.yml#93 (part of zackees/ci.yml#37 / #52, round M2-41).

The model

A main push runs minimal mode (ci/ci_mode.py), so on main only linux and dylints run. Both are on ubuntu-24.04 x64, and since #379 the ci-lint plan's cache_save is true only there. Full mode (ci-full PRs, dispatched candidate SHAs) restores caches but never saves, and the release and nightly macOS lanes pass save-cache: "false". So every declared family now has exactly one writer shape, per = "none", and each max is rounded up from the largest live main entry measured on 2026-09-29:

family	max	measured
deps (cook)	150MB	127,235,799 B
compile (thin build cache)	150MB	89,412,879 B
toolchain	210MB	179,728,890 B
dylint	600MB	544,405,988 B
dylint-out	700MB	619,600,131 B
soldr-mini	15MB	10,727,008 B
uv	5MB	<= 1,474,015 B

registry and sdk are no longer declared. Their live entries, along with the cross-target build caches, came from an older policy that saved from full-mode runs, and nothing writes them any more. The new test_main_writers_are_linux_x64_only pins this assumption: push is minimal, every plan-saving step is linux/dylints on ubuntu-24.04, or is gated to full mode. I checked it RED by removing build's full-mode if:, and the test failed.

Evidence

• Static CACHE-004 at ci.yml@78506e7: worst case 28,521,267,200 B -> 2,967,470,080 B (steady 1,918,894,080 + lockfile peak 1,048,576,000), against a budget of 10,200,547,328 B. precheck violations 910 -> 909.
• Live cleanup used ci-lint's own ops against this model, driven through gh api so no token was handled:
  • ci-lint cache janitor deleted 21 entries: 12 undeclared (4 prepared-SDK, 7 cargo-registry, plus the poisoned 237 B macOS registry as CACHE-005), 8 superseded setup-uv (including 2 of merged PR Bound native crash sampling and reuse module inventory #360's), and the superseded dylint-output generation.
  • The other 4 PR Bound native crash sampling and reuse module inventory #360 setup-uv entries share their key with a main entry, and the janitor collapses entries by key (cache trim/janitor: entries keyed by cache key collapse across refs (can target the wrong id) ci.yml#137), so I deleted them with ci-lint cache heal --key K --ref refs/pull/360/merge. The main entries with the same keys are intact.
• Live cache audit:

	entries	bytes	% of budget	findings
before (this model)	47	9,831,988,007	96.4%	CACHE-001 x12, 003 x6, 004, 005, 006 x13, 008 x6, GEN-009
after	22	5,445,167,494	53.4%	none

Not done

• Restore-only leftovers. 2 cross-target build caches (2.69 GB), 6 non-tnone/non-x64 toolchains and 2 soldr-mini entries still sit on main. They belong to declared families, so ci-lint reports nothing. Full-mode runs restore them and nothing refreshes them. They are why live usage (5.45 GB) is above the static model (2.97 GB). I left them in place so ci-full runs stay warm until they age out.
• D1-D5 scenario evidence (the template case study's cold/warm/lockfile/PR scenarios) was not produced in this round.

[zackees]

CI on this PR (run 36575614913) was cancelled by the Dylint job's "Cancel the run" step. setup-soldr failed there on a 404 for https://zackees.github.io/soldr-toolchain/sha256/4a94228b573cb8955cef1bfbb8751cca6b0f1c753058fa3394aea3a91ac722f7/rust-nightly-versions.v1.json, and main run 36574818064 hit the same failure on both attempts.

This is upstream and unrelated to this ci.toml/test change:

• soldr-toolchain's Refresh release manifest (13:11 UTC) updated catalogue.v1.json on the assets branch to a new content-addressed Pages URL.
• Pages is deployed only by the daily publish-multipart.yml cron (15 8 * * *), so the URL 404s until the next publish.

Re-run this PR's CI once that URL returns 200, then merge if it is green.