The bug: midiviz resolved its ALSA source port ONCE at startup and shelled
out to `aseqdump -p <port>`. Unplugging the LCXL removes the ALSA client it
was subscribed to, `aseqdump`'s stdout hits EOF, the reader thread's for-loop
just returns, and nothing else was keeping `app.exec()` alive — the window
closed with exit 0. Because that is a CLEAN exit, `Restart=on-failure` never
fired, so PLN's "always open" glyph-rain lens was gone for the rest of the
session the moment he unplugged the board. Reproduced from tonight's own
journal: `midiviz.service` ran 6m57s and exited status=0/SUCCESS the instant
the surface came off USB — textbook rig failure mode #1, "a binding resolved
once, killed by a replug, never re-resolved", except this time the binding
was the whole window's reason to exist rather than just a port variable.

The fix, mirroring the resolve/rebind pattern already proven in
`tools/lcxl-leds.py` (`find_seq_port` + `invalidate_ports`, cached and
dropped on failure):

- `Reader` now tracks `.alive()` (child process poll) and marks itself
  `error = "closed"` when its `aseqdump` child exits on its own (vs. an
  intentional `.close()`), so the difference between "I quit" and "I died"
  is visible to the widget.
- `MidiViz` gained a second QTimer (`RECONNECT_MS = 2000`, matching
  `midi-autoconnect.sh`'s own reconcile cadence) that re-resolves the source
  every tick and swaps the `Reader` in place if it moved, died, or vanished.
  Losing the source is never fatal any more: the window drops to its
  existing idle/dim-pulse paint state (already built for "no events
  recently") and keeps ticking, painting, and listening for the surface's
  return — no `sys.exit`, no fatal path added anywhere.
- Liveness is gated by `_hardware_present()`, a `type=kernel` + name-match
  scan of `aconnect -l` reused from `midi-autoconnect.sh`'s
  `DIRECT_LEG_AWK` (`hw = ($0 ~ /type=kernel/ && $0 ~ /Launch Control
  XL|LCXL/)`). This matters because `lcxl3-driver.service` publishes a
  VIRTUAL port literally named 'ParVagues LCXL3' — the translated,
  corpus-numbered stream `resolve_watch_port()` deliberately prefers, since
  that is the CC numbering the grid and every `.tidal` file actually speak.
  That virtual client can outlive a physical unplug for a beat if the driver
  hasn't noticed yet, so a bare name match would report "still connected"
  against a ghost carrying nothing. The rebind tick distrusts a match ONLY
  when the matched label is itself LCXL-named and no real hardware backs
  it; a "Midi Through" catch-all match needs no hardware and is trusted as
  before. Content still comes from the preferred (possibly virtual)
  port — only the "is it actually there" judgement moved to hardware.
- A user-pinned `-p` port keeps working, checked instead against
  `aseqdump -l`'s live listing (a pin surviving a client renumbering across
  replug is not guaranteed, same as any other resolved-by-address binding).
- `tools/midiviz.service`: `Restart=on-failure` → `Restart=always` +
  `StartLimitIntervalSec=0` (moved to `[Unit]`, where it belongs — the first
  install attempt logged "Unknown key 'StartLimitIntervalSec' in section
  [Service], ignoring", caught before it shipped) as belt-and-braces under
  the in-process fix, since the unit holds no audio ports and a restart
  loop costs nothing real.

Verified:
- `--selftest`: `parsed=68 ingested=250 frames=159 paints=170 grabs=83
  distinct_sampled_colours=165 platform=offscreen -> PASS`.
- Reinstalled the unit (`install -m644` + `daemon-reload`); no more "Unknown
  key" warning in the journal on the next start.
- Live restart: `ActiveState=active`, `MainPID=2728202`, `NRestarts=0`,
  bound to the "Midi Through" fallback (no LCXL physically plugged in
  tonight, confirming the hardware-gated fallback still works with zero
  surface present).
- Port-loss simulation (couldn't unplug hardware; killed the reader's
  `aseqdump` child directly — the same failure shape as the source
  disappearing under it): child pid 2728206 -> `<defunct>`; within the next
  2s rebind tick a fresh `aseqdump -p 14:0` (pid 2730846) appeared as
  midiviz's child. Main PID stayed 2728202 throughout, `NRestarts` stayed 0,
  `ActiveState` stayed `active` — recovered entirely IN-PROCESS, no systemd
  restart needed. CPU time kept accumulating (1.237s over 38s wall) proving
  the paint timer never stopped ticking.