No beforeunload guard; reload or update discards unflushed edits

[BootBlock]

grep -rn "beforeunload" src/ returns nothing. Closing the tab, reloading, or accepting the PWA update discards any edit still inside the autosave debounce window, with no prompt.

src/ui/PwaUpdatePrompt.tsx states the intended guarantee:

the page is never reloaded out from under an unsaved project

but nothing flushes or warns before update() reloads. The only flush trigger is visibilitychange → hidden in session.ts, which is fire-and-forget across a worker boundary and is not guaranteed to complete before the page is torn down.

The unsaved-dot is live in the transport bar, so the app already knows when there is unflushed work — it simply never acts on that knowledge at unload time.

Suggested fix

Register a beforeunload handler while modifiedSinceLastSave is true, and make the update prompt flush (awaiting saveNow()) before calling update(). Note that beforeunload cannot await an async flush, so it should warn rather than promise to save; the reliable flush belongs on the update path and on visibilitychange.

Related: the autosave-on-project-switch gap is tracked separately, and together these mean there is currently no guaranteed flush point at all.

[BootBlock]

Fixed in 926f2a0 (merged to main).

installUnloadGuard (src/core/project/unloadGuard.ts) attaches a beforeunload handler while modifiedSinceLastSave is true and detaches when the queue drains — attaching only while dirty keeps the page eligible for the back/forward cache. As suggested, the handler warns rather than promising a save, though it does fire a best-effort saveNow() that usually lands while the confirmation dialog is up.

The update prompt controls its own reload, so it now awaits saveNow() before activating the waiting worker; a failed flush is already surfaced by the autosave error toast and doesn't block the reload.

Verified in Edge against a preview build: no warning on a clean project, a warning armed within the debounce window after a mixer edit, and none again after an explicit save.

One thing found along the way and not fixed here: useTransportStore.setBpm is a plain set with no markDirty, so tempo edits never mark the project modified and are not autosaved at all. That's a separate defect from this one — worth its own ticket.