cats plugin: prune companion report artifacts alongside run databases

[ericfitz]

Deliberately deferred from #587.

keep_runs prunes cats-results-<run_id>.db files (and their -wal/-shm sidecars) but leaves the matching report-<run_id>.html / report-<run_id>/ artifacts behind, so the directory still grows.

Kept out of #587 on purpose: that change's whole risk profile is irreversible deletion, so the deletion surface was held to exactly one filename pattern. Widening it deserves its own review.

Pruning companions should key off the same run_id already captured from the database filename.

[ericfitz]

Implemented in the plugin (dev/cats-fixes-tmi-578-581-587 in ~/Projects/skills, unpushed).

Pruning now removes each dropped run's report-<run_id>/ directory and report-<run_id>.* files, keyed off the run_id already parsed out of the database filename — so the deletion surface is still exactly "artifacts of a run we just decided to drop", which is what #587 was protecting.

Two deliberate narrowings, given the issue's point that widening a deletion surface deserves its own review:

• Matching is exact (report-<run_id>, or report-<run_id>.<ext>), not a report-<run_id>* glob. A report-20260727T204514Z-annotated directory that someone deliberately kept survives.
• A companion is removed only after its database was successfully unlinked. A failed unlink leaves a run present, and that run must keep its evidence.

Five tests cover it: companions of pruned runs go, companions of surviving runs stay, --dry-run touches nothing, the suffixed sibling survives, and a mocked unlink failure leaves that run's companion intact. One pre-existing test (test_non_matching_filenames_are_never_candidates) asserted a report file survives pruning; it named a run_id that gets pruned, so it now names a surviving one — the assertion it was actually making is unchanged.

[ericfitz]

Fixed in the cats plugin by f9d340a. Pruning now removes each dropped run's report-<run_id> directory and report-<run_id>.* files alongside its database.

Two deliberate properties: matching is exact rather than a report-<run_id>* glob, so a deliberately-kept report-<run_id>-annotated survives; and a companion is deleted only after its database was successfully unlinked, so a failed unlink can't orphan the evidence for a run that is still present.