store: max_terminal_runs deletes the runs it was documented to delete (#875)

[Masterplanner25]

Closes #875.

The defect

max_terminal_runs is documented as the hard ceiling on a store's size — "a
host that keeps a store for years and wants a hard ceiling sets this". It was
not one. _prune_terminal_runs chose what to delete from the age-bounded
listing, which drops terminal runs older than terminal_max_age_days — and
terminal is exactly what it deletes. So the only records it could see were the
ones it was least meant to remove.

max_terminal_runs=2, six finished runs, four aged past the bound
  -> 6 files on disk, and the four survivors were the four oldest

The exact inverse of the intent: prune the recent history, keep the old forever.

One keyword, because #869 added the unbounded listing this needed.

The safety property

Live runs are untouched at any age. The guarantee is the
status in TERMINAL_RUN_STATUSES filter and does not depend on which listing
feeds it — but that is a claim about code, so the test runs it: every live
status (waiting, running, pending, retry_scheduled) is made the oldest
record in the store and survives a prune.

With a control asserting finished runs are pruned in the same call. Without
it the safety test passes on a build where the cap deletes nothing at all.

Behaviour change

This deletes strictly more, so the changelog flags a "not additive" row at
release. It is opt-in — max_terminal_runs defaults to None, and an unset cap
still deletes nothing (asserted) — so only a host that asked for a ceiling is
affected, and it now gets the one it asked for.

The cost objection was void

I wrote in #875 that prune "would now read every file — the same trade #869 made,
on a hotter path". That was written before #869 landed and is wrong: the listing
already reads every file, because a run's status is only knowable by loading
it. The flag adds no I/O at all. What it adds is materialising records the bound
used to discard after paying for them:

400 aged terminal records: 53 ms without, 65 ms with

I had written "It costs nothing" into the docstring before measuring. It is 53 →
65 ms, and the docstring says so now. Pruning also shrinks the directory, so it
is self-limiting in a way the un-pruned case never was.

Two of my own tests were broken

The neuter run is what showed it — the headline test did not fail against a
deliberately reverted fix:

• save_run rewrites the record, so ageing inside the helper and then saving left
  every file fresh at prune time. Records are aged after the last save now,
  and the prune is triggered by a separate fresh record.
• The source assertion matched the docstring, which explains the fix and so
  contains include_aged_terminal=True. It reads the body with the docstring
  stripped now — the same unfalsifiable shape as input_fn in BUG-868: a cross-process resume runs on a child VM with no tool_registry or effect_store, so tool.call fails soft and the run reports success #868.

Re-run after both fixes, the first neuter goes from 1 failure to 4:

BASELINE (fixed tree)                                    53 passed
the cap reads the age-bounded listing (the 5.14 rule)    RED   4 failed
the cap may delete any status, not just terminal         RED   4 failed
the cap keeps the oldest instead of the newest           RED   5 failed
RESTORED                                                 53 passed

Checks — the full four-step sequence

1. targeted pytest (cap, parked runs, framework, migration, store lifecycle,
   key order, resume bounds): 89 passed
2. nodus_gate --all: ten phases green
3. release probes: 130/130
4. python -m unittest over this file plus its neighbours including
   test_workflow_step_writes: 84 tests, OK — the BUG-873: a resume child VM inherits no run budget, so resume_workflow is unbounded work inside a bounded program #873 lesson, since this
   file's prune touches CWD-relative graph state

ruff and mypy src/nodus/ clean.

🤖 Generated with Claude Code