BrowserSidecarAdapter persists sessions that production standalone deliberately drops

[nedtwigg]

TauriAdapter deliberately persists nothing. The flag is explicit, and its
comment ties the decision to the workspaces-rollout scope:

// standalone/src/tauri-adapter.ts:564
private static PERSIST_SESSION = false;

readonly persistsSession = TauriAdapter.PERSIST_SESSION;

saveState(state: unknown): void {
  if (!TauriAdapter.PERSIST_SESSION) return;
  ...
}
getState(): unknown {
  if (!TauriAdapter.PERSIST_SESSION) return null;
  ...
}

BrowserSidecarAdapter — the adapter behind pnpm dev:standalone:ab — has no
such gate and routes both calls straight to localStorage:

// standalone/src/browser-sidecar-adapter.ts:259
saveState(state: unknown): void {
  try { saveSessionState(localStorage, BrowserSidecarAdapter.STATE_KEY, state); }
  catch { console.error('[browser-sidecar] Failed to save session state'); }
}

getState(): unknown {
  try { return loadSessionState(localStorage, BrowserSidecarAdapter.STATE_KEY); }
  catch { return null; }
}

It also leaves persistsSession absent, which docs/specs/transport.md defines
as reading true.

Consequence: the browser dev harness restores panes across a reload that
production standalone deliberately drops. Anyone debugging session
save/restore behavior through the harness is exercising a code path the real
app does not take, and a stale localStorage blob can carry state between runs
that would not survive in the shipped product.

The harness contract says it "must preserve the PlatformAdapter … contracts
used by the app", which argues for adding the same gate. The counter-argument
is that pane persistence across a reload is a genuine convenience while
iterating in a browser tab — in which case the divergence should be documented
in docs/specs/standalone.md rather than silently inherited.

Either resolution is fine; the current state is that neither was chosen
deliberately. Flagging for a decision.

Found during the spec audit in #; left unchanged because it is a behavior
change, not a documentation fix.

[dormouse-bot]

Picked the mirror-the-gate resolution in #477 — BrowserSidecarAdapter now carries the same PERSIST_SESSION = false flag, reports persistsSession: false, and deletes any pre-gate localStorage blob on init(). Four tests in standalone/src/browser-sidecar-adapter.test.ts fail on main and pass there; CI is green.

Three things tipped it away from documenting the divergence. docs/specs/standalone.md already argues the gate is load-bearing rather than cosmetic — persistsSession: false makes saveSession skip the record build, and with it a getCwd round trip per pane on every debounce and 30s heartbeat, which in the harness means a bridge hop into the sidecar's synchronous lsof. dev-agent-browser.mjs gives each run its own temp state dir explicitly so a dev run never touches installed state, and localStorage was the one slot leaking across runs — with transcripts in it. And since absent persistsSession reads true, the harness was contradicting the documented standalone answer, not just behaving differently.

Delete-on-init rather than ignore-the-key, for the same reason TauriAdapter.init calls clear_session: a blob already in a developer's profile would otherwise stay there indefinitely.

The convenience you flagged is recoverable exactly as it is for TauriAdapter — flip the flag locally — and the spec now says to flip both together when workspaces-rollout turns persistence on. Happy to invert this to the documented-divergence resolution if you'd rather keep the reload behavior.