Count MLX's retained cache in the harness watchdogs

[IonDen]

The showcase, benchmark, latent-capture and A/B harness workers each run under a watchdog thread that aborts the process before it can exhaust unified memory. Until now that thread compared MLX's active memory against the ceiling. MLX keeps freed buffers in a retained cache that is still resident, and it reports that cache separately, so the number the watchdog compared was not the number MLX considers in use. Under the harness caps the memory limit already drains that cache before any allocation that would cross it (checked on mlx 0.32.2 with synthetic buffers), so this was never an open door to a kernel panic; it was a reading that could not say how close a run actually came, and a policy the report could not state.

Both watchdogs (scripts/run_showcase.py, scripts/_capture_latent.py) now sample active plus cached bytes and compare the sum against the ceiling. Each one bounds the cache pool with mx.set_cache_limit when it starts, so every model-loading path gets the bound from the same place and the abort artifact can state it: 4 GiB for the generation workers, 4 GiB for the decode reps (their heaviest peak is 3.7 GiB, so the timed decode still runs from a warm pool), and the A/B script passes its existing per-condition bounds through. Polling moves from 0.5 s to 50 ms; both getters are plain reads and the poll runs while mx.eval holds no GIL. The watchdog keeps high-water marks of the sum it compares and of the cache term alone, and each worker records those next to the policy (ceiling, cache bound, cadence, wall budget): in the showcase live result, in the bench sentinel and the per-condition report block, and in the A/B unit result. A memory sample that raises used to kill the daemon thread and leave the run with no backstop; it now aborts with reason sample_error and the error text, and the orchestrators print every term the watchdog compared.

Nothing in the library changes. The showcase report and COMPARISON numbers were not re-measured; COMPARISON says which accounting its numbers came from. The 4 GiB live bound was checked against the committed live wall clocks: live_preview at 512x512 ran three interleaved reps at 4 GiB and at 20 GiB, median 10.76 s against 11.07 s, with the retained pool topping out at about 4.1 GiB against 17 GiB, so the bound is neutral for the timings and only limits how much the process holds at teardown.

Evidence: 19 new offline tests drive the real watchdog thread against a fake MLX memory API, and each was checked against the one-line bug it names (dropping the cache from the sum, skipping the cache bound, installing it after the first sample, a swallowed sample error, a cadence regression, a rep worker inheriting the live bound, a result or report block that omits the policy or the observed peak, an orchestrator message that hides the cache term or the error text, the A/B condition-to-cap mapping collapsing). On the M1 Max, a throwaway check with a 1.5 GiB synthetic ceiling aborted a worker whose active memory was 0.9 GiB and retained cache 0.8 GiB (exit 70, artifact showing both terms), and let a 1.0 GiB cached-only run finish. Full suite: 558 passed, coverage 98.6%.