Revert dev ribbon to mount-time-only; drop the vite:afterUpdate self-subscription

The "true last build" version subscribed to import.meta.hot.on(
'vite:afterUpdate', ...) from App.tsx -- the same file that keeps
getting hot-edited during normal iteration. React Fast Refresh didn't
reliably clean up the old listener across repeated hot-swaps of that
module, and the ribbon started ticking every second in the real
desktop app (confirmed via ps/lsof this wasn't a stale-tab/stale-process
issue -- a fresh Playwright tab against the same live dev server showed
it static). Not worth chasing further for a dev-convenience ribbon.
Back to capturing the timestamp once per mount, which is correct for
the case that actually matters (a Go-triggered relaunch forces a fresh
mount) and can't have this bug class at all.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7zUjYuMtgetjNaxMQPg2h

Author: alicoding

docs/SPEC.md

@@ -380,6 +380,21 @@ that environment, on something testable directly in this dev session:
   own inline result block on Runbook, just for the headless hotkey path.
   Empty `Result` (failure case) means no expand affordance at all, not an
   empty expanded block. `LOCKED`
+- **Small `DEV` ribbon (top-right, App.tsx) answers "am I looking at a dev
+  build, and is it current."** Gated on `import.meta.env.DEV` (true only
+  under a real `vite serve` process — verified directly that this is
+  false for `vite build` regardless of `--mode`, see the repo-layout
+  section above). Shows a timestamp captured once per mount — correct for
+  a Go-triggered relaunch (the common case that actually needs checking),
+  not for a frontend-only HMR edit that never remounts. A fancier version
+  tried tracking true "last build" via `import.meta.hot.on('vite:after
+  Update', ...)` and was reverted: subscribing to that event from
+  `App.tsx`, the very file that keeps getting hot-edited, hit React Fast
+  Refresh not reliably cleaning up the old listener across repeated
+  hot-swaps of the same module — stray listeners kept firing. Not worth
+  chasing further for a dev-convenience ribbon; mount-time-only is simpler
+  and can't have that bug class. `LOCKED` (mount-time approach) / noted so
+  the HMR-self-subscription approach isn't retried blind.
 - **Progressive enhancement by permission, not a hard gate.** `LOCKED`
   Zero-permission floor: browsing the Runbook and running an action by
   clicking it always works, no OS permission required. Accessibility

frontend/src/App.tsx

@@ -26,10 +26,15 @@ function App() {
   const [time, setTime] = useState<string>('Listening for Time event...');
   const [actions, setActions] = useState<Action[] | null>(null);
   const [activity, setActivity] = useState<ActivityEntry[]>([]);
-  // Captured once per mount. A Go-file change forces a full app reload
-  // (Go isn't hot-reloadable, unlike frontend-only edits which apply via
-  // Vite HMR without remounting) -- so this timestamp doubles as "when
-  // did the last Go rebuild actually land," not just page-load trivia.
+  // Captured once per mount -- correct for a Go-triggered relaunch (Go
+  // isn't hot-reloadable, so a Go change forces a fresh mount) but not
+  // for a frontend-only HMR edit, which updates live without remounting.
+  // A vite:afterUpdate-based "true last build" version was tried and
+  // reverted: subscribing to it from App.tsx, the same file that keeps
+  // getting hot-edited, hit a real bug where React Fast Refresh didn't
+  // reliably clean up the old listener across repeated hot-swaps of this
+  // module, leaving stray listeners firing on unrelated updates. Not
+  // worth chasing further for a dev-convenience ribbon -- see SPEC.md.
   const [loadedAt] = useState(() => new Date().toLocaleTimeString());
 
   useEffect(() => {