feat(cleanup): make idle-destroy disk-pressure-aware, remove inert runtime-gc

[V3RON]

Closes #22. The issue said either resolution was acceptable per feature, so: disk pressure is implemented, runtime GC is removed. Reasoning for each choice below, since they went opposite ways.

Disk pressure — implemented

Removing it would have meant dropping diskPressure.freeBytesThreshold, a config key that is already validated and documented, so the honest cheap direction was to make it do what the docs imply.

idle-destroy now reads diskFreeBytes off the view — which the reaper was already computing and no rule was reading — and shortens its own threshold from T2 to T1 when free space is under the configured threshold. No new config keys. The reason string names pressure as the cause, per safety rule 6: disk pressure (free 2GiB < 10GiB): idle 12m > T1=10m.

The behaviour deliberately does not flow through the event bus. The reaper emits disk.pressure-detected as a post-commit observer fact, edge-triggered so a sustained condition emits once per crossing rather than once per tick, but the rule stays a pure function of the view and never depends on an event having fired (safety rule 3). The existing subscription is kept so an external emitter can still wake the reaper.

One defect found in review and fixed here: the crossing check initially sat in #view(), which every run shares — so pitlane cleanup --dry-run under pressure would emit the fact, wake this reaper through its own subscription, and turn a preview into a real cleanup run. A dry run must stay a preview (safety rule 5). The fact is now noted only on runs that execute, and the test pins it by counting rule evaluations: without the guard, the preview evaluates twice — once for itself, once for the run it woke.

Runtime GC — removed

Implementing it needs an Android system-image inventory the driver doesn't expose, so it would be a feature, not a fix. runtime-gc.ts, its registration, the gc-runtime CleanupAction, and the runtime.deleted event declaration are gone, along with the docs/CLI.md and docs/ARCHITECTURE.md claims that it works. iOS runtimes stay Xcode-managed regardless.

Consequence that had to be handled: runtimeGcRule was the only entry in manualCleanupRules, and #rulesFor(name) filtered --rule against manual rules only — so removing it would have left cleanup --rule matching nothing at all. In fact --rule idle-destroy already matched nothing today, which is a live bug this surfaces. --rule <name> now selects across the rules that actually exist, so both idle-shutdown and idle-destroy work, manualCleanupRules is gone rather than left as an empty exported list, and list --rules reports the real registry.

Tests

• idle-destroy: destroys at T1 under pressure with pressure named in the reason; still waits for T2 when not under pressure; never proposes a leased device under pressure (safety rule 2).
• reaper: emits once per crossing and not per sustained tick, and again after recovering and re-crossing; --rule selects by name across the registered rules; the dry-run test above.

Verification

pnpm run check green (505 unit, 28 e2e) and pnpm fallow --ci clean — re-run independently after the review fix, not only as reported.

---

Generated by Claude Code