Wipe local data: add one-click Clear-Site-Data trigger once off GitHub Pages

[Stvad]

Context

The lock_and_wipe_local_data ("Wipe all local data") panic action currently delegates the actual destruction to the browser/OS "clear site data" control: it drains unsynced uploads, then shows the user concise instructions for clearing the site's data. It does not trigger the wipe programmatically.

That's deliberate — see docs/lock-and-wipe-coarse-recommendation.md §0 (the analysis) and the implementation in src/shortcuts/defaultShortcuts.ts.

Why no programmatic trigger today

The clean one-click trigger is a dedicated origin route (e.g. /wipe) that responds with Clear-Site-Data: "*"; the app navigates there and the browser wipes the origin. But:

• The header must come from a network response on our own origin, and we ship on GitHub Pages, which can't set custom response headers.

• A service worker can not stand in for that. Verified by spike (docs/clear-site-data-spike/, Chromium 141):

  • SW that synthesizes the header (new Response('', {headers})) → ignored, nothing cleared.
  • SW that passes through a real network response carrying it → cleared, but that still needs our origin's server to emit the header.
  • Plain network response / navigation with the header → cleared.

  i.e. Chromium only honors Clear-Site-Data on responses that came over the network; GH Pages can't produce one.

There's also no JS API to open the browser's clear-data UI from a page, so guidance is the only option on GH Pages.

What to do when we're on a header-capable host

When the app moves to (or sits behind) an origin that can set response headers — e.g. a small edge function / Worker, Cloudflare Pages, Netlify, or a real server:

1. Add a /wipe route on our origin that responds with Clear-Site-Data: "*" (or "cache","cookies","storage","executionContexts") and redirects to the logged-out app.
2. Update lock_and_wipe_local_data to: confirm → flushUploadQueue (already in src/sync/flushUploadQueue.ts) → navigate to /wipe for a true one-click wipe, falling back to the current guide text when the header route isn't available.
3. Re-run / extend the spike on the target host to confirm the header is honored there (and ideally check Firefox/Safari, which the spike didn't cover — only Chromium was installed).

References

• docs/lock-and-wipe-coarse-recommendation.md §0.2 (trigger pattern), §0.3 (hosting reality), §0.4 (when to hand-roll)
• docs/clear-site-data-spike/ (reproducible spike + results)
• Implementation: src/shortcuts/defaultShortcuts.ts (lock_and_wipe_local_data, WIPE_LOCAL_DATA_INSTRUCTIONS)