feat(cards): cap height + collapsible inline approval/ask/path-grant cards

[juacker]

What

Make the inline approval / ask_user / path-grant cards behave well when
they're tall or stacked. Each card now:

1. Caps its body at min(60vh, 600px) with internal scrolling, so a long
   ask_user prompt (or three cards stacked) can no longer swallow the
   conversation.
2. Has a collapsible header — click ▾ / ▸ to squish the body to a
   one-line summary so the user can peek at the conversation behind a
   pending card, then expand to act.

Default state is expanded (the card is waiting for an action). ask_user
auto-resets to expanded on each new question; the list cards track collapse
per requestId so flipping workspace or re-issuing doesn't lose state.

Why

F9 surfaced in the Windows QA doc: inline cards had no max-height and no
internal overflow, so an ask_user with eight long options, or several
cards stacked, grew unbounded and pushed the conversation out of view.

The fix keeps the cards embedded in the conversation flow (where they
already are — that's the right model for "decisions need conversation
context") and fixes the actual defect: unbounded growth. I deliberately
did not float/minimize them away from their context.

Where it lives

• src/components/AskUserPanel/AskUserPanel.tsx
• src/components/AskUserPanel/AskUserPanel.module.css
• src/components/InlineApprovalCard.tsx
• src/components/InlineApprovalCard.module.css
• src/components/InlinePathGrantCard.tsx
• src/components/InlinePathGrantCard.module.css

Tests

• Existing suites kept green (no behavior change when cards are empty/short).
• 2 new collapse regression tests (AskUserPanel, InlineApprovalCard).
• Full gate: tsc / eslint --max-warnings 0 / vitest (128, +2) /
  vite build all clean on the linux-latest branch CI (Check & Build).

Manual verification (since F9 is a visual concern)

Tested locally on the branch — three card shapes:

1. ask_user — long question + 8 long options renders capped, scroll
   internally, header toggle hides the body and shows the question summary.
2. Approval — a curl invocation triggers the approval card; cap +
   collapse work; after approval the command runs (exit 7 here, expected).
3. Path-grant — not yet triggered by hand but the component path is the
   same as InlineApprovalCard (same CSS hooks).

Heads-up for future readers

bash_exec policy full (everything allowed) does not produce a card
for an unknown binary — the shell just returns "not found" before any
permission gate can intercept. To exercise the approval card during manual
testing, run something the policy actually gates (network access,
confirm-required prefix, sensitive path read). This is true on every
release, not introduced here.

Not in this PR (deliberate follow-ups)

A "pending action" pill pinned near the composer that appears only when a
pending card is scrolled out of view — covers the one scenario embedding
doesn't handle on its own. Worth a separate PR if you find yourself
scrolling past waiting prompts often.