feat(#463): File menu creates, imports and exports Dashboards workspace-wide

[BorisTyshkevich]

What & why

Closes #463.

The File menu's three Dashboard commands still assumed one exact Dashboard was
already open — a model that stopped fitting once a workspace can hold many.
There was no New dashboard… at all; Import Dashboard… was disabled on
Query with Open a dashboard and, where it did work, replaced whichever
Dashboard was open; and Export Dashboard… was unavailable unless one was on
screen, even with Dashboards in the workspace to choose from.

All three become workspace operations.

New dashboard… — a new row, immediately after New workspace…. Prompts
for a name, appends an empty Dashboard through app.mutateWorkspace, opens it in
Edit mode. Duplicate names allowed (identity is the id); Cancel/Escape commit
nothing; a rejected commit leaves navigation and local state untouched.

Import dashboard… — additive on every surface, including Query.
planImportDashboard now appends a freshly reminted document, which let its
three-way targeting go entirely: targetDashboardId, the compatibility slot,
requireEmptyCollection, the two stale-target diagnostics that guarded them, and
the destructive Import and replace current Dashboard? confirm. There is no
parameter left that can name an existing entry. The plan reports the local id it
minted, so the import opens what it just added.

Export dashboard… — workspace-aware. Zero Dashboards disables it with No
dashboards; the Dashboard on screen exports in one click (View as well as Edit);
a sole Dashboard exports directly from Query too; otherwise a chooser lists tile
count plus an id fragment so duplicate names stay distinguishable. Every export
resolves an exact id — no dashboards[0] fallback remains to reach.

FileMenuContext takes dashboardIds instead of dashboardCount: export has to
name a target, and a bare count cannot without the caller reaching back into the
aggregate and re-deciding there. Rows regroup by verb — create / import / export
/ download — behind three separators; the two Dashboard labels drop to sentence
case. Row order, separators, labels, availability and reason text stay the pure
model's alone, and context still changes enabled state only.

Owner decision taken during the run

The issue's "multiple Dashboards with an exact Dashboard currently open:
preselect that Dashboard" reads two ways. Owner chose: export it directly,
no chooser — exporting the Dashboard you are looking at stays one click. The
chooser appears only when no exact Dashboard resolves.

Review round (second commit)

• Import did not open the imported Dashboard in Edit mode, which the issue
  requires — an append is otherwise invisible and read as a silent no-op.
• Export was gated on the id list alone, which the workspace-not-found surface
  can populate from a stale state.dashboard.
• openDialogShell now returns focus to the File trigger on close (the issue
  lists focus return under Tests).
• README's File-menu section still described the pre-Refactor File menu for multi-Dashboard creation, import, and export #463 menu.
• The export-chooser meta test used 6-character ids, so it could not fail if the
  id fragment widened to the whole id.

Owner feedback + review round two (third commit)

• Creating or importing from the Query surface left the sidebar on Databases.
  The Dashboard opened, but the tree that lists it — and marks it selected —
  stayed behind the other tab. Both commands now switch state.upperRole to
  dashboards as well; a refused commit changes neither.
• P1 — export could retarget to another workspace. Dashboard ids are unique
  within a workspace, and an imported workspace keeps the ids it was exported
  with. The export awaits the write queue, then re-read app.state.workspaceId
  on the far side of that await — so switching workspace mid-flush let an
  exact-id lookup succeed against the new workspace. The workspace is now
  pinned when the export is chosen (chooser included) and the degraded state
  fallback only applies while it is still current. exportWorkspaceAction got
  the same pin.
• P2 — the chooser left keyboard users behind the modal. It now focuses its
  first Dashboard row, and openDialogShell traps Tab inside the card (pulling
  focus back in from outside, skipping disabled controls).
• P2 — duplicate rows were not guaranteed distinguishable. A fixed six-character
  id tail is no tiebreaker (sales-abcdef / ops-abcdef). The new pure
  shortIdFragments widens the tail until every listed fragment differs, falling
  back to the whole id. The import chooser shows one too — reminting after import
  doesn't stop the id identifying the source documents while choosing.

Review round three (fourth commit)

• P1 — the degraded workspace export could drop a Dashboard. currentWorkspace()
  folded the live projection back through the compatibility slot (entry 0), but
  since Add dashboard selection state and a full-size dashboard work surface #425 that projection is the selected Dashboard: [A, B] with B on
  screen reconstructed as [B, B]. It now folds back by exact id, leaves the
  committed collection alone when the projection names no stored entry, and seats
  it only when nothing is stored. file-menu.ts no longer touches the
  compatibility slot at all.
• P2 — a pinned export could still take the new workspace's name. The bytes
  were pinned; the file name came from live state after the flush. The request
  now carries workspaceName too, and both exports name themselves from committed
  truth when it loads and the pinned name otherwise (which is also the fallback an
  empty — schema-valid — Dashboard title uses).
• P2 — a stale chooser target could open an empty modal and throw. Nothing
  closes an open menu when a cross-tab refresh lands, so a choose decision whose
  Dashboards were all removed opened a row-less chooser and threw focusing row
  zero. The Export row re-resolves through liveContext + fileMenuModel on
  activation: gone → toast, narrowed to one → direct export, still many → chooser.

Verification

npm test (5661 tests, per-file gate), tsc --noEmit, npm run check:arch,
npm run build, and Playwright chromium + webkit (269 passed; Firefox cannot
launch in this sandbox and is covered by CI).

Verified live against the served build: the nine rows and their reasons on Query
and on a Dashboard, the name prompt (light + dark, default preselected), create →
Dashboard surface in Edit mode, a second Dashboard under the same name, direct
export from an open Dashboard, re-importing that bundle → appended (2 → 3) and
opened in Edit, the chooser from Query showing three identically-named rows
distinguished by id fragment, and focus returning to the File button on Escape.
No console errors.

Filed #481 (inbox): the empty-Dashboard placeholder's Create dashboard
button is now a second Dashboard-creation path with different UX and a different
write primitive — deferred rather than folded in, since #463's non-goals cover
the adjacent rename/+-button work.

Checklist

• npm test passes (the per-file coverage gate is non-negotiable)
• Tests added/updated in the same change as the code
• npm run build succeeds (single-file dist/sql.html)
• Layers kept honest: pure logic in src/core/, network in src/net/ (injected fetch), DOM in src/ui/
• No new runtime dependency (or it's a deliberate, justified addition — see CONTRIBUTING)
• README / CHANGELOG.md ([Unreleased]) updated if behavior or the deployed surface changed
• Reconciled affected tracked work (roadmap Roadmap to 1.0.0 #68, the issue body, ADR/CHANGELOG) if this change reshaped it