PLN: "ensure i can close midi mon atm it forces on when i want the gui/tray to
allow run and or close? its too sticky atm ahah" -- the second report of the
same complaint, because the first fix was committed and never made live: the
shared checkout still runs 5468507b, so tonight's midiviz has neither the X nor
the latch. The code was right and the deploy was missing, which from where he
sits is indistinguishable from not being fixed.

Adds the other half he asked for: launchers.stop(key), and a "Close ▸" entry
under Rig.

Closability is OPT-IN per launcher, keyed on declaring a systemd unit. A
generic close-anything row is one mis-click from stopping Ardour mid-set, and
this menu's whole value is being safe to touch while playing. Only the MIDI
lens opts in today; a test asserts ardour/pulsar/supercollider never quietly
acquire it.

Close ▸ is a separate submenu rather than a Raise/Close pair on each row. The
rows have one job mid-set -- one click raises the tool you need -- and putting
a Close next to that is the mis-click itself. So closing lives in one place,
holds only what is running AND closable, and is empty and disabled otherwise.

The latch is written BEFORE anything is stopped. ensure() runs from gig-up and
the Bridge watcher, a converge can land in the same second, and a latch
written afterwards races it -- the window returns and the close looks broken,
which is the exact complaint. A test pins the ORDER, not just the outcome.

stop() prefers `systemctl --user stop` where a unit owns the process: killing
it directly leaves systemd's view wrong, and for a unit with Restart= systemd
is what decides next. Where there is no unit it SIGTERMs, using a /proc walk
rather than pgrep -f -- the Bash wrapper embeds our own command line, so
pgrep -f matching would find this session and the kill would take down the
tool doing the killing. Same identity rule as is_running(), so "it says
running" and "this is what I would kill" cannot disagree.

And it confirms instead of assuming: it polls for up to 2s and returns
"still-running" if the process outlives the request. Reporting a clean close
while the window is still on screen is the same class of lie as this morning's
delete that reported 0/14 for fourteen successful deletions.