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.