PLN: "i rightclick the perf indicator and see no gear status?"

He was right, and the state had been there all along. launchers.is_running()
existed; _build_menu() just ran ONCE at startup and read only `available`. So a
running Ardour looked identical to a stopped one, and — worse — the safe action
("do nothing, it's already up") looked identical to the dangerous one. Two
SuperColliders is a zombie port 6010 and a silent rig.

Now: a `Gear ▸ 3/6 up` submenu, each row labelled with what it IS —
  ● Pulsar — running     (greyed: launching a second one is never what you meant)
  ○ MIDI Monitor         (clickable)
  ✗ Something — not installed
Glyphs rather than colour, because a tray menu inherits the desktop palette and
this gets read in a dark room seconds before playing. Web tools stay clickable
when running, since clicking them opens a URL rather than spawning a duplicate.
Refreshed on menu-OPEN only, never on the 2 s icon timer: reading gear state walks
/proc, and doing that 30x a minute for a label nobody is looking at is exactly the
per-tick cost this rig keeps getting bitten by.

THREE REAL BUGS FOUND WHILE WIRING IT UP, each worse than the missing label

1. THE TRAY OPENED THE WRONG ARDOUR SESSION. ARDOUR_SESSION pointed at
   "Tidal Multi" — the older ARCHIVE of per-orbit recordings — not "Tidal Live",
   the session that performs and records the stems. Any faders touched there would
   have been the wrong ones. Auditing that same archive as if it were live already
   produced a confidently wrong fader report on 2026-07-28; this was the same
   mixup one layer down, waiting to happen again 6 days before OPAL.

2. IT COULD NEVER HAVE LAUNCHED ARDOUR ANYWAY. Candidates were
   ardour8/7/6/ardour; the installed binary is ardour9 (real exe `ardour-9.2.0`).
   So the entry reported "unavailable" and greyed itself out while Ardour was
   running on the same machine.

3. THE RUNNING CHECK MATCHED THE WHOLE WORLD. `pgrep -f ardour` matched the
   `tidal-ardour-autoroute.sh` helper script AND any shell whose command line
   merely mentioned the word — including the shell I was testing from. So it could
   report Ardour UP while Ardour was DOWN, which is worse than reporting nothing,
   because it is the state you act on. is_running now matches the EXECUTABLE
   basename (`exe`), with full-line matching kept only for interpreted tools where
   argv[0] is `python3` and the identity is the script path.

AND IT NO LONGER FORKS
is_running was one `pgrep` subprocess PER launcher, and snapshot() is called by
the web Bridge's poll as well as the tray. Replaced with a single forkless /proc
scan shared across the whole snapshot: 6 items in 10.7 ms, zero forks, down from
6 forks per refresh. Same lesson as the LED daemon's per-event fork and gig-log's
per-sample sampling — on an audio rig, do not pay a process for a boolean.

Verified live: all six entries now report correctly (Pulsar/Ardour/QjackCtl up,
MIDI Monitor + Foundry + Armada down); perf-tray restarted and active.

TESTS: +11 in test_launchers.py, suite 424 -> 435, all green. Pinned: the
autoroute-script and bare-shell false positives; a version-suffixed binary
(ardour-9.2.0, and a hypothetical ardour-10.0.1) matching; a filename ending in
".ardour" NOT counting as a running Ardour; snapshot() scanning /proc exactly once;
is_running spawning no subprocess at all (subprocess.run/Popen monkeypatched to
raise); and the session path being the LIVE one with "Tidal Multi" absent.