[nanotchec]

Ocarina of Time's large warm pipeline archive was being compacted again on ordinary launches, adding preparation work without enough new cache content to justify it.

Keep the existing compaction policy for small archives. For a large archive, require sufficient growth before compacting again, and preserve the existing safeguards and archive contents. No cache is deleted to make startup appear faster.

Rebased on official main d8b2b64a1fc5, retaining its CI repairs. Also document the DM_TEST_ARCHIVE_LARGE fixture switch, which the environment-table check correctly reported missing.

Validation on the current sources, Apple M3 Max:

• Metal archive fixture: 145 checks, zero failures, Metal validation enabled.
• Python archive, documentation, environment-table and Xcode preparation checks: 21 tests, two intentional skips, no failures.
• Diff check clean. GitHub checks are rerunning; no new gameplay timing is claimed for this rebase.

Scope: this avoids unnecessary archive compaction. It does not persist native mesh pipelines that the driver evicts, and does not guarantee the optional expanded mesh prewarm will finish quickly on every launch. The separately reported failed-flush marker behavior remains outside this patch.

Front-ends: no changes required. No game files, keys, saves or cache archives are included.

[padsiwono]

A second way the same compaction repeats, in case it fits here: arch_write_file removes the compacting marker after the flush whether or not the write succeeded (if (ep->compacting) unlink(...) right after serializeAsArchiveAndFlushToURL, nvn_mtl.m on main 7f502220). A failed write sets g_compact_bad, so the old files stay, but with the marker gone arch_compact_allowed lets the next start compact again, and the comment above it ("A failed flush of this method disables compaction on this OS build") never takes effect.

We hit it before eed7c429, when the write failed in Metal (the MDB_MAP_FULL case eed7c429 fixed): Ocarina of Time v131072 with #1732's list spent 415 to 522 s preparing on five starts in a row (M5 Max, macOS 26.6). Keeping the marker when the write failed,

if (ep->compacting && ok) unlink(arch_compact_marker().fileSystemRepresentation);

brought the next three starts to 3.63, 3.66 and 3.67 s, with the same picture and frame times. Since eed7c429 that failure no longer happens here, so this only matters for other write errors; happy to open it as a one-line PR instead if you'd rather keep this PR to its own case.