"i see the parvagues tray icon, but doesnt react when i click" — twice, with
the unit green both times. Three findings, in the order they mattered:

- The menu WAS exported and populated all along (19 rows over
  com.canonical.dbusmenu). What made it useless is the style: with
  QT_QPA_PLATFORMTHEME=qt5ct and no qt5ct config under the unit, Qt picks
  `qt5ct-style` with a bare #efefef palette — a 2009 grey box on a Yaru
  desktop. Now: Fusion, plus an explicit dark palette when the desktop asks
  for dark (GNOME's color-scheme is the one setting that knows).
- The tray host on GNOME is an EXTENSION, and it registers its
  StatusNotifierWatcher seconds after login. perf-tray printed "No system
  tray available", exited 1, and only Restart= saved it 3 s later. A slower
  login loses that race. Now it waits up to 120 s, polling on a QTimer
  (availability arrives over D-Bus, so the event loop has to be spinning).
- New check `perf-tray reachable`: unit active, item REGISTERED with the live
  pid (a stale item from an old pid looks identical on screen), and the menu
  populated over dbusmenu — the only one of the three that a click needs.
  Negative-tested against a stopped tray.

Also:
- `wireplumber churn` check: starts per hour, and who asked for them. The
  existing checks could only see the wreckage (a failed unit, a dummy sink);
  this sees the cause while audio still works. It FAILs on tonight's 48.
- The kwin midiviz-pin check asked KDE questions on a GNOME session, so it
  warned forever about a file that will never exist. Desktop-aware now: a
  check that cries wolf is one nobody reads on the day it is right.