Keyboard-accessible "Add to dashboard…" command for Library queries

[BorisTyshkevich]

Goal

Adding icon action to the query in Library.
Each Library row should expose a "plus" icon before the pencil. Clicking on it opens a chooser. The chooser contains:

1. Prose about adding a query to the dashboard
2. Dashboard selection (one of the opened)
3. Add and Cancel buttons.

The chooser calls the same application commands as drag/drop and produces
identical data — that equivalence is the whole point, and is what the tests
must assert.

Adding query to Variables is not supported here.

What #428 already built for this

The command layer is done and needs no change. This issue is UI only:

• src/core/library-drag.ts — LibraryQueryDragPayload, LibraryDropTarget.
• src/dashboard/application/library-assignment.ts — the pure transforms
  copyLibraryQueryToPanel and the LibraryAssignmentAbort vocabulary.
• src/application/library-assignment-service.ts —
  assignLibraryQueryToPanel , including the in-transform dirty-variable-tab gate and libraryAssignmentMessage.

Call those. Do not reimplement the semantics, and do not let the chooser reach
mutateWorkspace directly.

Implementation notes

• A new src/ui/library-assign-menu.ts built on ui/menu.ts's openMenu.
  Two stages, both anchored on the row's trigger: dashboards → . menu.ts:125 already closes stage 1
  before the callback runs, so there is no reopen race.
• The affordance on the Library row (a ⋯ kebab beside star/edit/delete, an
  inline +, or a kebab that absorbs edit/delete) is an open design decision —
  the row's existing controls are saved-history.ts:216-248.
• Add src/ui/library-assign-menu.ts to the source list in
  tests/unit/typography-contract.test.js (~:298-320). A new markup-bearing
  UI module that is not on that list escapes the "every rendered class has a CSS
  rule" gate and can ship as unstyled user-agent chrome — which is precisely the
  failure that test's header comment describes.

Acceptance criteria

• Every Library row exposes Add to dashboard…, reachable by keyboard alone.
• The chooser offers Dashboard → Panel
• Panel assignment through the chooser produce candidates
  byte-identical to the equivalent drag, asserted against the same service.
• Full keyboard operation: open, arrow between rows, Escape closes, focus
  returns to the trigger.
• src/ui/library-assign-menu.ts is on the typography-contract source list.

Non-goals

• Re-opening the curated-filter configuration form. There is no parameter
  picker, target-panel picker, default picker, selection-mode picker, or
  provider mapping (Add Library drag assignment to Dashboard panels and variables #428 non-goal, still binding).
• Changing the drag path's semantics.
• Touch-specific interaction.
• The existing editor-subquery drag, which stays separate from this chooser.

[BorisTyshkevich]

Triage note (2026-07-27) — stays with #428's lineage; deliberately not folded
into #429.

#429 was just consolidated into the single owner of Dashboard-tree management
and click operations (it absorbed #472, #443, #449, #431, #476, #481). This issue
was considered for that fold and kept out, because two things distinguish it:

1. It is a Library-row affordance, not a Dashboard-tree one. The command hangs
   off saved-history.ts's row controls; the Dashboard tree is only the
   destination the chooser names.
2. Its command layer is Add Library drag assignment to Dashboard panels and variables #428's, already built — copyLibraryQueryToPanel /
   copyLibraryQuerySqlToVariable, assignLibraryQueryToPanel /
   assignLibraryQuerySqlToVariable, and the LibraryAssignmentAbort vocabulary.
   The whole point of this issue is that the chooser produces data identical to the
   drag path, which ties its tests to Add Library drag assignment to Dashboard panels and variables #428, not to Dashboard tree management: direct Dashboard and Panel actions #429's edit/delete planners.

Folding it into #429 would have meant one issue owning two different rows' command
surfaces over two different application layers.

Recorded as an explicit non-goal in #429 and in #430's follow-up list so it does
not get pulled in by proximity later. Nothing here changes: still the open
accessibility gap for #428's acceptance bullet 9, still the only route a keyboard
or touch user has to Library→Dashboard assignment.