Dashboard/Workbench cross-tab optimistic concurrency (revision CAS)

[BorisTyshkevich]

Context — deferred from #341

#341 made the editable Dashboard and Workbench two editors over one committed StoredWorkspaceV1, with all edits (dashboard commands, saved-query mutations, import/replace) flowing through the single per-tab app.serializeWrite queue. That guarantees same-tab write ordering and consistent same-tab projection/export.

It does not protect against a cross-tab stale overwrite: WorkspaceRepository.commit() is documented last-write-wins with no compare-and-swap (src/workspace/workspace-repository.ts). Two browser tabs (Dashboard in one, Workbench in another) each hold their own serializeWrite chain and their own committedWorkspace baseline. If tab A commits, tab B's next commit — built from B's now-stale baseline — silently clobbers A's change. #341's own "Cross-tab minimum contract" section explicitly allows deferring this as long as reload consistency holds (it does) and same-tab writes are strictly serialized (they are).

Goal

Detect and refuse a stale cross-tab overwrite instead of silently clobbering. Options (pick one during design):

• Revision CAS in the repository: commit(candidate, expectedRevision?) compares the persisted workspace/dashboard revision and returns a typed conflict result when it moved; callers surface a "workspace changed in another tab — reload" affordance.
• Storage-event / BroadcastChannel invalidation: a tab that observes another tab's commit refreshes its committedWorkspace baseline (and re-projects) before its next write.

Acceptance

• A commit built from a stale baseline (another tab committed since) does not silently overwrite the newer workspace.
• The stale tab gets a clear, recoverable signal (conflict result and/or reload prompt), not a lost update.
• Same-tab behavior from Keep Dashboard and Workbench on one committed workspace state and make exports consistent #341 is unchanged.

Non-goals

• Server-side / cloud workspace sync (out of scope, per Keep Dashboard and Workbench on one committed workspace state and make exports consistent #341 non-goals).
• Live real-time cross-tab mirroring beyond conflict-safety + reload consistency.

Filed as a scoped follow-up per #341's "Cross-tab minimum contract" section.

[BorisTyshkevich]

Reconciling this issue with PR #344's review-driven rework, plus an implementation plan.

What changed since this was filed: there is no per-route/per-tab "baseline" variable anymore. Every producer (Dashboard commands, saved-query mutations, File-menu import/rename/replace) now commits through app.mutateWorkspace(transform), whose queued op reads workspace.loadCurrent() at dequeue time and builds the candidate from that. Since IndexedDB is shared across tabs, a tab's transform already sees the other tab's commits. The remaining cross-tab exposure is therefore narrower than this issue's body describes:

1. the read-modify-write race between one tab's loadCurrent() and its commit() (the other tab can commit in that window — still a silent lost update, just a much smaller window);
2. stale render: the losing tab's UI keeps showing its own projection until its next write/reload (no invalidation signal).

Plan:

1. CAS in the repository (closes exposure 1). commit(candidate, opts?: { expectToken }) where the token is the previously-loaded record's identity — simplest robust token: the raw canonical encoded JSON text (or a hash of it) captured by loadCurrent, compared inside the same IndexedDB transaction as the write. Avoids adding a workspace-level revision field to the schema (dashboard.revision doesn't cover saved-query mutations). New typed result: { ok:false, conflict:true }.
2. Retry loop in mutateWorkspace. On conflict, reload + re-run the transform (bounded, e.g. 3 attempts) — Dashboard command descriptors and File-menu plan builders are already re-applied against whatever latest is, so cross-tab rebase falls out of fix(#341): one committed workspace for Dashboard + Workbench, consistent exports #344's design for free. Only after exhausting retries surface the conflict diagnostic.
3. Cross-tab invalidation (closes exposure 2). BroadcastChannel('asb:workspace') posted after every successful commit (storage-event fallback isn't available for IndexedDB, so BC only; absence of BC = no signal, CAS still protects writes). Receiving tabs refresh committed truth: project via applyCommittedWorkspace and, on the Dashboard route, reuse fix(#341): one committed workspace for Dashboard + Workbench, consistent exports #344's rebuild path (renderDashboard re-reads loadCurrent) when the document/membership changed.
4. Tests: two repository instances over one shared fake store interleaving commits (CAS conflict + retry-rebase both-changes-survive); a fake BroadcastChannel seam (injected via env, like fetch/crypto) for the invalidation projection.

Same-tab behavior from #341/#344 stays unchanged; the acceptance criteria in the body above still hold verbatim.