Take 94 came back with no track trail, and there was no way to tell from the logs
whether the watcher had seen the track changes, failed to bind them, or simply
never run. It had been running for 2h46m. It had emitted nothing but systemd's own
start/stop lines the entire time.

Two independent causes, and either alone is enough to blind the unit:

1. Python BLOCK-buffers stdout when it is a pipe, and under systemd it always is.
   Even the lines that were being printed would have sat unflushed in a 4 KB
   buffer. Fixed with Environment=PYTHONUNBUFFERED=1 in the unit.

2. `--watch -q` suppressed the track-change line itself, so there was nothing to
   flush. That is the wrong thing to make quiet. `quiet` should mean "no per-CC
   chatter" — thousands of lines an hour — not "never say what you are painting",
   which is a handful of lines an hour and the entire purpose of the daemon. The
   track-change log is now unconditional.

Verified live rather than by reading: restarted the unit, wrote a different track
to ~/.cache/parvagues/current-track, restored the original, and read the journal
back. Both transitions appear with their binding counts (desire 28 controls,
vague_de_crime 20), and a re-parse of the same file is labelled distinctly from a
real track change — that distinction matters because an edit-and-save must keep
the touched-state while a genuine track change must clear it.

Same family as the stale-binding pattern this rig keeps producing: something
resolved once, invalidated by an event, with no error anywhere. Here the error
reporting itself was the thing that had been silently resolved to /dev/null.