Edits made while disconnected are silently lost on reload — no prominent warning, no leave-page confirmation

Description

When the collaboration websocket drops while a user is editing, the editor keeps accepting input — those edits exist only in browser memory. If the user then reloads the page, navigates away or closes the tab (which is a common reaction to seeing the browser/OS show "no internet"), everything typed during the dead window is silently discarded. The server later persists the partial state as a new revision, so the loss is permanent and does not appear in history.

We verified this server-side on a self-hosted instance: content typed during a 15-minute websocket dead window never arrived on any subsequent connection, and the revision created afterwards contained only the pre-drop prefix of a paragraph.

Two UX gaps make this worse:

1. The only disconnect indicator is a small "Offline" pill in the document footer (ConnectionStatus component), which is display: none below the tablet breakpoint — on narrow windows there is no indication at all, and even when visible it is easy to miss (tooltip only on hover).
2. There is no beforeunload confirmation for documents with potentially unsynced edits. The codebase already uses this pattern in TemplateForm for unsaved template changes, but not for collaborative documents.

Steps to reproduce

1. Open a document for editing.
2. Break the websocket connection only (e.g. block the /collaboration ws request in devtools, or drop server reachability while keeping the page open).
3. Keep typing. Note the near-invisible footer indicator.
4. Reload the page.
5. Everything typed in step 3 is gone; the server never received it.

Expected behavior

• A prominent, persistent banner (not a footer pill) while multiplayerStatus is connecting/disconnected on an editable document, shown at all viewport widths, telling the user edits are not syncing yet.
• A beforeunload confirmation ("Leave site? Changes you made may not be saved") while there may be unsynced local changes — e.g. while the multiplayer status is not connected, or the local ydoc has updates not yet acknowledged by the server.

Related

• #5830 — data loss with zero client-side warning (closed, still receiving reports)
• #12106 — same report ("connection lost with no warning"), closed
• #13464 — clicking Done destroys the websocket before final edits sync

Unlike those reports, this issue is specifically about the missing warning/guard UX, which is reproducible on demand and cheap to fix.

Environment

Self-hosted, multiplayer collaboration enabled, recent version (self-built image).