BUG: Sessions dropdown stays empty after window reloads — stale client-side session cache is never invalidated #293

Summary

On a fleet client, the panel's Sessions dropdown remained empty across multiple
window reloads even though the hub held all sessions, the session-list APIs
returned them when queried directly, and the same app displayed them in a
regular browser. The hub's request log showed the webview made no session-list
requests at all: it served a persisted empty snapshot from client-side storage
instead of re-fetching on boot.

Context

• Desktop app panel (webview iframe) on a fleet client; hub on Linux x64.
• Engine: hub binary was a pre-v1.18.10-amicode.21 build at first observation,
  then upgraded to v1.18.10-amicode.22 — the empty dropdown persisted across
  both, isolating the fault to client-side persisted state, not the hub.
• Extension vendored-engine pin in the affected install: v1.17.3-amicode.4.
• Server-side data was verified healthy throughout (direct API queries returned
  hundreds of sessions).

Expected vs actual

• Expected: reopening or reloading the panel rebuilds session lists from the
  server; persisted client state is invalidated/refetched on boot (or at least
  clearable from inside the product).
• Actual: the webview served an empty cached session list indefinitely; the
  request log contained zero session-list requests across all reloads. Recovery
  required manually deleting the client's webview cache/storage folders.

Reproduction sketch

1. Get the client into a state where a session list fetched empty (e.g. server
   downtime or a scoping mismatch at first boot).
2. Fix the server side.
3. Reload the window / reopen the panel — the dropdown still shows nothing; no
   session-list request is issued.

intake: not-ready — mature per the maturity contract before picking up
suggested_path: B
diagnostics: inline
upstream: none found