PWA §5: wire cache-purge-on-logout + SPA logout affordance (SW handler exists, trigger doesn't)

[MartinCastroAlvarez]

Security review follow-up (recent-code review, 2026-05-27).

The PWA service worker ships a dar:purge message handler (#200/#208 — verifies origin, deletes all dar:v1:* caches). But nothing on the frontend sends it, and the SPA has no logout affordance at all (login #190 landed; logout did not). grep for dar:purge / caches.delete / client.logout in frontend/apps/web/src returns nothing.

Risk

Low today. Every API read is Cache-Control: no-store, so the SW never caches a payload — there's nothing to leak to a later user of the same browser. This is an incomplete defense-in-depth control, not an active vulnerability. It becomes load-bearing the moment a consumer opts into any cacheable read policy (the proposed PWA_API_CACHE_SECONDS).

What's owed (frontend, ~small)

A logout flow in the SPA that, on logout:

1. client.logout() (the JSON endpoint exists, feat(auth): package serves its own login — replaces admin login when admin is off #168).
2. navigator.serviceWorker.controller?.postMessage({ type: 'dar:purge' }) — fires the SW handler.
3. Clears the dar: localStorage namespace (the clearAll() helper noted in @dar/data README).
4. Redirects to the login page.

Plus a Logout affordance in the user menu / sidebar (Django-admin parity — the admin has logout).

Out of scope

The SW-side handler is already done (#200). This is purely the frontend trigger + UX.

— filed by the Security & Compliance Lead during the recent-code review.

[MartinCastroAlvarez]

Done via #363. Added @dar/data purgeLocalCache() (wipes the dar:* localStorage namespace, preserving only dar:theme) and a Log out affordance in the Settings dialog that calls it before reloading. Combined with the existing service-worker handler, sign-out now clears cached data at rest. Closing.