Move Dashboard navigation and file operations out of the Workbench File menu

[BorisTyshkevich]

✅ Reconciled design (2026-07-18) — implemented with #288

Implemented together with #288 on branch feat/dashboard-viewing-288.
Owner refinements to the spec below (this section wins on conflict; original
kept for history). See ADR-0003.

• Dashboard → opens a new tab, not the current tab. The dashboard opened
  from the Workbench header shares the workspace id / dashboard id and the
  IndexedDB workspace store with the Workbench, and stays in edit mode
  (drag reorder + layout preset persist to the shared store). Opening in a new
  tab (rather than same-tab navigation) keeps the Workbench tab available and
  reuses the existing new-tab credential handoff. Accessible name stays
  Open Dashboard. The route carries ?ws=<workspaceId>&dash=<dashboardId>
  and verifies both ids (not-found on mismatch).
• The Dashboard header File menu gains a third item: "Open for viewing…"
  (in addition to Import Dashboard… / Export Dashboard…). It opens a new tab
  in read-only view mode holding a detached snapshot of the current
  dashboard — its own detached store + fresh ids, survives relogin, unaffected
  by later Workbench edits. Transport is the Dashboard v1 phase 6 (#280): direct + full-screen viewing with one-time IndexedDB handoff #288 one-time IndexedDB token.
• Everything else in this issue (moving Dashboard nav/import/export out of the
  Workbench File menu into the Workbench header + the Dashboard File menu) is
  implemented as written.

---

Problem

The Workbench File menu mixes workspace, query, Dashboard navigation, Dashboard import/export, variable-history, and publishing operations. It has become too long and does not clearly communicate which resource each action affects.

Dashboard is an explicit resource in the current workspace and has its own standalone page. Dashboard navigation and Dashboard-specific file operations should move closer to that resource.

Workbench header

Add a Dashboard → control immediately after the current workspace name.

• Show it only when the current workspace contains a Dashboard.
• Open the existing standalone Dashboard route in the current tab in a new tab (owner override — see reconciled section).
• Accessible name: Open Dashboard.
• Treat it as navigation, not a dropdown or external link.
• On narrow screens it may collapse to an icon-only button while retaining its accessible name.

Remove Open as dashboard from the Workbench File menu.

Workbench File menu

The Workbench File menu owns workspace and query-collection operations only.

Keep:

• New workspace…
• Remember recent variable values
• Clear all recent values
• Import queries…
• Replace workspace…
• Export workspace…
• Download Markdown
• Download SQL
• workspace query-count footer

Remove:

• the Dashboard section;
• Open as dashboard;
• Import Dashboard…;
• Export Dashboard….

Do not change workspace/query import or export formats or semantics.

Dashboard header

Add a File menu to the standalone Dashboard header, positioned with the Dashboard-level controls.

The Dashboard File menu contains:

• Import Dashboard…
• Export Dashboard…
• Open for viewing… (opens a detached read-only view-mode tab — see reconciled section / Dashboard v1 phase 6 (#280): direct + full-screen viewing with one-time IndexedDB handoff #288)

Export Dashboard… exports the current Dashboard dependency closure through the canonical portable-bundle format. Export is read-only and must not change workspace identity or Dashboard revision.

Import Dashboard… must use the existing transactional Dashboard import planner. The standalone viewer must not directly mutate persisted workspace state.

Import flow:

1. Select and parse the bundle without executing SQL.
2. Validate it and select a Dashboard when the bundle contains several.
3. Hand off to the Workbench-owned conflict-resolution/import flow.
4. Build and validate the complete candidate workspace.
5. Commit atomically after explicit confirmation.
6. Return to the Dashboard route after success.
7. Cancellation or failure leaves the current workspace and Dashboard unchanged.

For an externally opened Dashboard, opening alone must remain non-importing. The import action imports that Dashboard into the current workspace through the same planner.

Accessibility

• Dashboard → has accessible name Open Dashboard.
• File menu buttons expose menu state with aria-expanded.
• Menus support keyboard opening, arrow navigation, Enter/Space activation, Escape dismissal, outside-click dismissal, and focus restoration.
• Existing confirmation dialogs and accessible names remain intact.

Responsive behavior

• Workbench may render Dashboard → as icon-only on narrow screens.
• Dashboard may render File as an icon-only menu button on narrow screens.
• Back navigation, title, theme, and Refresh remain reachable.
• Do not introduce new header wrapping at supported mobile widths.

Tests

Cover:

• Dashboard control shown when a Dashboard exists;
• Dashboard control absent when no Dashboard exists;
• Dashboard control opens the standalone Dashboard;
• Workbench File menu contains no Dashboard actions;
• Workbench File menu retains workspace/query actions;
• Dashboard File menu contains Dashboard import and export;
• Dashboard export emits the correct dependency closure;
• Dashboard import uses the transactional planner and commits atomically;
• cancelled or invalid import leaves the workspace unchanged;
• external open remains non-importing;
• keyboard and responsive menu behavior.

Acceptance criteria

• Dashboard navigation is adjacent to the workspace name.
• Workbench File menu contains no Dashboard section or Dashboard import/export operations.
• Dashboard page has its own resource-scoped File menu.
• Dashboard export works directly from the Dashboard page.
• Dashboard import uses Workbench-owned conflict resolution and atomic commit.
• Standalone viewing alone never mutates the current workspace.
• Mobile and keyboard accessibility behavior is preserved.
• No portable-format, schema, execution, or persistence semantics change.

Non-goals

• multiple Dashboard management;
• Dashboard folders or selectors;
• editing Dashboard layout in the standalone viewer;
• changing portable bundle schemas;
• changing query import or workspace replacement semantics;
• adding a Dashboard dropdown to the Workbench header.