The report ended an unclosed log with:

    ⚠ no `end` record — the recorder is still running, or it was killed

Both readings are plausible and the reader has no way to pick. I picked wrong:
I asked systemd about `parvagues-gig-log` — a name I guessed instead of read; the
unit is `gig-log.service` — got "inactive", and used that false negative to
resolve the ambiguity into "killed". The recorder had in fact been up for eleven
hours, enabled, with its pw-top and aseqdump children alive, still writing. A
whole task got filed about restoring a service that was never down.

Two mistakes worth naming because they chain: guessing an identifier rather than
reading it, and then letting a broken check settle a question the tool had
deliberately left open. The wording invited exactly that.

So the tool now decides and says which:

    ● RECORDING NOW — this log is still open, numbers are partial
    ⚠ no `end` record and no recent sample: the recorder was KILLED

is_live() decides from the DATA's own recency — last sample within a few periods
of now — and deliberately not from a process match. `pgrep -f` matches any shell
that merely mentions the string, and unit names are exactly the thing I just got
wrong. Recency needs no name and nothing to guess.

86 tests (was 83): a live log must say RECORDING NOW and never KILLED, a stale one
the reverse, and is_live must answer from timestamps alone.