The black box writes ~72 MB/hour into a gitignored directory and nothing
deleted anything, so it only grew: a rehearsal week is >5 GB and the repo's
">500 MB is reported or deleted, never silent" line bites after one.
An automatic sweep is the wrong shape here. A timer or an ExecStopPost is the
one mechanism that could delete the take nobody meant to keep, which is the
entire reason the recorder exists. So: `prune [DAYS]`, dry by default. It
prints what it would remove and removes nothing until --yes.
Three things are never candidates, in the order they would hurt:
* whatever the running recorder holds open, read from /proc/PID/fd rather
than guessed from mtime — after a segment roll the newest file is not the
one being written, and a long session's current segment can easily be
older than the window. A held-back file is named BEFORE the
nothing-to-do line, or the report would be a lie about the one file that
matters most (the test that found this).
* anything that is not a %Y-%m-%d_%H%M%S.opus segment, so a slice_*
excerpt cut on purpose is not swept up with the raw capture.
* anything inside KEEP_DAYS (14, overridable).
OUT_DIR is overridable with GIG_RECORD_DIR for one reason: a delete command
whose tests cannot run without pointing at real takes is a delete command
nobody tests. The six new tests assert what it REFUSES to delete, including
a real process holding a real fd.
The gate advises at 500 MB and names the command. It never prunes.
