feat(amicode): "Inspect Run" button on the entity rail

[kateebonner]

What

Adds an "Inspect Run" button to the Amicode problem-header rail, beside the live run chip. Clicking it opens the VS Code Run Inspector panel on demand.

Why

Paired change with harmoniqs/amicode#116, which stops the Run Inspector from auto-launching when a solve starts. With auto-launch off, users need an explicit, discoverable way to open the inspector from the chat — this is it.

How it works (reuses the existing bridge — nothing new)

The button fires postAmicode("amicode.openInspector"), posting {source:"amicode", kind:"command", command:"amicode.openInspector"} to window.parent. The extension's chat_panel.ts relay forwards it and executes the command, which is already in BRIDGE_ALLOWED_COMMANDS. No new bridge lane, allowlist entry, or server route.

Changes

• packages/ui/src/amicode/entity-rail.tsx — new optional onInspectRun?: () => void prop and an "Inspect Run" button, gated on a run existing (hasRun, mirroring the rail's existing run-status logic) so it appears alongside the run chip, not before any solve. packages/ui stays bridge-agnostic — it only fires the callback.
• packages/app/src/pages/session/message-timeline.tsx — wires onInspectRun to the bridge, passed only when framed in Amicode (inAmicode()), so the public web/share build renders nothing.
• packages/app/src/pages/session/use-amicode-commands.tsx — export postAmicode + inAmicode for reuse (previously palette-only).

Placement

Chosen surface: the entity-rail run chip (persistent, always visible while a solve is active). Alternative was the inline solve tool card (card.tsx); easy to move if preferred.

Rollout ordering ⚠️

amicode vendors a built opencode binary, so this button only reaches users after this PR merges and the rebuilt binary is re-vendored into harmoniqs/amicode (a follow-up amicode PR). It has no effect on the public web build.

Verification

⚠️ Build/typecheck/lint gates were not run in the authoring environment (no bun/node toolchain available). Please run the repo's UI/app checks before merge. No existing tests reference these surfaces; the new prop is optional (non-breaking).

🤖 Generated with Claude Code

[kateebonner]

✅ Checks run green (toolchain bootstrapped locally):

• packages/ui typecheck (tsgo --noEmit) → exit 0
• packages/app typecheck (tsgo -b) → exit 0
• New test packages/app/src/pages/session/use-amicode-commands.test.ts → 3/3 pass

The test locks the bridge contract the button depends on: postAmicode posts exactly {source:"amicode", kind:"command", command:"amicode.openInspector"} (the command chat_panel.ts allowlists), never throws on a rejecting parent, and inAmicode() is false when unframed (button hidden on the public web build).

ℹ️ Note: Solid components can't be DOM-rendered under this repo's bun test harness (no Vite/vitest/happydom in packages/ui), so the button's render is covered at the bridge-contract level rather than a full DOM render. Verified the PR2 UI live via vite dev — the served rail module contains the button.