Importing a Dashboard bounces the user back to the Query surface

[BorisTyshkevich]

Spotted while shipping #452 (unified File menu); deferred as out of scope there.

What happens

Importing a Dashboard onto an exact active Dashboard drops the user back to the
Query surface, even though they imported into the Dashboard they were
looking at.

Why

planImportDashboard(..., mode: 'copy', ...) remints the document id
(src/workspace/import-planner.ts:453-455):

const finalDashboard: DashboardDocumentV1 = mode === 'copy'
  ? { ...rewritten.dashboard, id: genId(), revision: 1 }
  : rewritten.dashboard;

replaceDashboard then swaps it into the target's slot under the NEW id, so the
id held in mainSurface.dashboardId no longer resolves. The commit projection
runs reconcileMainSurface, which correctly refuses to guess and falls back to
QUERY_SURFACE (src/application/main-surface.ts:130), and app.ts's
lost-selection path then rewrites the route and repaints Query
(src/ui/app.ts:1751-1760, :1815-1828).

Every step is behaving as designed. The composite outcome is still wrong for the
user.

Why deferred

Pre-existing (predates #452) and orthogonal to "one File menu" — #452 changed
which Dashboard is targeted, not what happens after the commit. Fixing it means
re-selecting the imported document after a successful commit, which needs the
minted id threaded back out of the commit (the data channel on
mutateWorkspace can carry it) and an openDashboard call — a behaviour change
#452 does not ask for. It is currently PINNED by test, not fixed.

Suggested fix

Thread the imported Dashboard's new id back through commitWorkspace's data
channel and app.openDashboard({ dashboardId: newId, mode: 'edit' }) on success,
so an import lands the user on what they just imported.

[BorisTyshkevich]

Fixed on main by #463 (PR #482, merged 2026-07-27). Closing.

Every step of the mechanism described here is gone:

• The remint-and-replace is gone. planImportDashboard no longer takes a
  mode and no longer calls replaceDashboard. It appends —
  normalizedForOwnership(appendDashboard(base, finalDashboard), …)
  (src/workspace/import-planner.ts:452) — so an import cannot swap a document
  into an existing slot under a new id, which was what made
  mainSurface.dashboardId stop resolving.
• The minted id is threaded back out, exactly as this issue's suggested fix
  proposed: the plan reports importedDashboardId (import-planner.ts:458).
• The user lands on what they imported. doImportDashboard calls
  revealDashboard(app, lastPlan.importedDashboardId) on a successful commit
  (src/ui/file-menu.ts:853), which opens the Dashboard in Edit mode and swaps
  the sidebar to the Dashboards tree.

reconcileMainSurface's refusal to guess — correct behaviour, and not the
problem — is therefore never triggered by an import any more, because the id the
surface holds is still in the collection.

Verified by reading the merged code, not by re-running the manual reproduction in
a browser. If you hit the bounce again on a current build, reopen and I'll chase
it from the live app rather than the diff.

Noted in #430's follow-up list.