Show a reload banner when a new version has deployed (#28)

The service worker already auto-updates in the background (registerType:
'autoUpdate' + an unconditional self.skipWaiting()), but that just
silently swaps the SW -- nothing ever told an already-open tab its
already-loaded JS had fallen behind, so a long-lived tab could run a
stale build indefinitely.

Switched registerType to 'prompt': a new SW now installs and waits
rather than taking over immediately, activating only when the page
explicitly asks (sw.ts's skipWaiting is now conditional on a
SKIP_WAITING message instead of unconditional). UpdateBanner.tsx uses
vite-plugin-pwa's virtual:pwa-register/react hook to surface that as a
small banner with a Reload button, and polls for updates hourly so a
tab that never navigates still notices eventually.

Verified a fresh install shows no banner (correct baseline) and the
code follows the documented registerType: 'prompt' pattern exactly.
Could not get this sandbox's browser to actually detect a swapped
service-worker file via registration.update() during testing --
confirmed via direct inspection that the server serves the new
content correctly and ruled out timing, so this looks like an
update-check limitation specific to this automated browser
environment rather than a bug; the real test is the next live deploy.

Also adds a "frontend-preview" launch.json entry (npm run preview) --
the only way to exercise the real production service worker locally,
same reasoning as vite.config.ts's existing `preview.proxy` section.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

frontend/src/sw.ts

@@ -7,7 +7,18 @@ import { NetworkFirst, NetworkOnly } from 'workbox-strategies'
 
 declare let self: ServiceWorkerGlobalScope
 
-self.skipWaiting()
+// registerType 'prompt' (vite.config.ts) means a newly-installed SW waits
+// in the "waiting" state, still fully cached and ready, rather than
+// unconditionally taking over -- it only activates once the page explicitly
+// asks (UpdateBanner.tsx's updateServiceWorker(), which posts this message)
+// after the user chooses to reload. Without this listener, skipWaiting()
+// would need to run unconditionally at install time, defeating the point
+// of asking first.
+self.addEventListener('message', (event) => {
+  if (event.data?.type === 'SKIP_WAITING') {
+    self.skipWaiting()
+  }
+})
 cleanupOutdatedCaches()
 
 // The app shell -- same effect generateSW gave us automatically in Phase 3.