Offer view-scoped actions in the quick palette

[andrewkchan]

What was wrong

The quick palette could only list app commands, so everything without a stable
AppCommandId behind it was unreachable from the keyboard: switching to a
named model, opening a particular thread, starting a thread in another project,
opening a workspace in a target that is not the preferred one. AppCommandId
is a closed enum the server owns, so those actions cannot become commands —
which left the palette a searchable view of the shortcuts a user already had.

What changed

Views can now contribute rows.

• palette-registry.ts — a provider registry plus
  useRegisterPaletteActions. A component registers a function, not an
  array, and the palette calls it when it opens, handing it the element that
  was focused beforehand. That is what makes scoping possible: every composer
  mounts a model picker and every split pane a thread view, so a static array
  would produce duplicate rows with no way to tell which surface owns them. A
  provider that throws is contained.
• useNavigationPaletteActions.ts (mounted by AppLayout) — a new thread
  in any project, and recent threads by title. Reads the sidebar bootstrap
  AppLayout already holds, so no extra query and no second realtime
  subscription. Capped at 15 threads and excludes the current one.
• ModelReasoningPicker.tsx — the focused composer's other models,
  reasoning efforts, and providers, by name. Scoped with the picker's existing
  ownsModelPickerCycleChord, which already resolves which of the mounted
  pickers a chord addresses from the focused pane, the caret's composer, and
  whether the picker is open. Reusing it keeps the palette and the cycle chords
  from drifting apart. This is also why the cycle commands are palette-hidden:
  they move one step against a picker the palette is covering up, whereas these
  rows name the destination.
• ThreadDetailView.tsx — one row per configured workspace open target,
  beside the workspace.openPreferred command that only ever opens the
  preferred one. Focused pane only.
• docs/configuration.md — what the palette lists beyond commands.

Rows that would do nothing are dropped throughout: the current model, effort,
and provider; options the picker would refuse; the thread already on screen.

No wire change, no new plugin API. HOST_DAEMON_PROTOCOL_VERSION untouched.

How you verified

10 tests: 9 unit and 1 integration.

• CommandPalette.test.tsx — a registered provider's row appears beside the
  app commands, receives the pre-open focused element, and runs. This covers
  registration and target passthrough end to end, so the registry's unit tests
  cover only what it cannot: that a provider reads current props through a ref
  rather than a stale closure, and that one throwing provider does not take the
  palette down with it.
• useNavigationPaletteActions.test.tsx — project rows include the personal
  project (a separate field from projects), recency ordering and title
  fallback, the cap plus current-thread exclusion, and the routes each row
  navigates to.
• palette-composer-actions.test.ts — which options become rows.

pnpm exec turbo run typecheck and lint clean for @bb/app (0 errors); the
app suite passes 3255. Each of the five commits typechecks on its own.

One pre-existing failure is unrelated and reproduces on clean main:
PluginIcon.test.tsx walks plugins/ and throws ENOENT on a stray empty
plugins/monaco/ directory in the local checkout.

AGENT GENERATED: by Claude Opus 5