[Douglasymlai]

Split out of #1958 so it can be reviewed on its own.

Problem

When an agent needs permission or asks a question, the request replaces the message box. The request is hard to tell apart from the normal composer, and technical details compete with the actual question. When one request is answered and another arrives right away, the next one can appear under the cursor, so a quick second click could answer a request you haven't read yet.

Cause

Approvals and questions were rendered as variants of the composer itself, in the same frame as the message input, with the full technical header.

Fix

• Approvals and agent questions now appear in a card directly above the message box. The message box stays visible but is disabled while the request is open. This works in both the default chat view and the event-based view.
• Approval cards show the request type, title and target (such as the file or URL), with a collapsed Review details section that lists the arguments (for example the command to run), then Reject and the approval options. "Approve once" is the primary action; broader scopes are secondary. If sending a decision fails, the error is shown in the card.
• Questions show the agent's question with a short divider above the answer field. Enter sends and Shift+Enter adds a new line, as before.
• The question answer field has no inner frame and shows a focus ring when focused. Other feedback fields keep their framed look.
• If a new request arrives after one has been answered, the card first shows Review next request. You choose to open it before its buttons appear.
• The card resets when you switch Sessions.
• Small alignment fixes so the card and composer line up: composer icons use the shared icon sizes, and the composer text inset matches the queued-message list.

How decisions are made does not change: the same requests, options and handlers are used, and a request leaves the screen at the same point as before.

New copy: "Review next request" (all 11 locales).

Testing

• npx vitest run on HumanDecisionCard.test.tsx (new), BottomBox.test.tsx, ControlInput.test.tsx and ChatBox.spaceModelSelection.test.tsx: 121 passed.
• All test/unit/components/ChatBox and test/unit/components/Workspace suites: 863 passed.
• npm run type-check, npm run check:i18n, npm run check:design-tokens, ESLint and Prettier on changed files, git diff --check: pass.
• Follow-up fix: bare legacy questions now use the same separate card above a disabled blank composer, retaining the existing human-reply handler.
• Fix regression validation: 14 focused interaction/card tests passed, plus 7 interaction tests repeated after restacking. Both new legacy-question tests fail against the old component; they cover placement, the disabled composer, keyboard submission and failed-reply retry.
• Real Electron retest in default and event-native Narrative views: separate question card/divider, disabled composer, Shift+Enter newline, Enter submission and completed answer passed. A later approval stayed behind Review next request until explicitly opened. Approve once wrote the expected file; Reject left its file absent. All four Tasks used the selected Gemini model, verified in durable model receipts. No approval outcome mismatch observed.
• Approval target and arguments: a new HumanDecisionCard.test.tsx case builds an approval through the event-based view with a target file and a command argument, and checks that the target and the Review details section with the command are shown. It fails if the card hides them again. HumanDecisionCard, BottomBox, ControlInput, ChatBox and ChatBox.spaceModelSelection suites: 241 passed.
• Question answer field: new textarea.test.tsx checks the borderless answer field style and that the default style is unchanged, and new ControlInput.test.tsx cases check that a question uses it and other feedback keeps the framed field. The new assertions fail without the change. test/unit/components/ui, HumanDecisionCard, BottomBox, ControlInput, ChatBox and ChatBox.spaceModelSelection suites: 257 passed. npm run check:design-system passes.
• Shared textarea: the borderless style is new and only the question answer field uses it. The existing styles are unchanged, and a test pins the default style's classes and padding. The other textarea callers (worker setup and tool selection, task editing, bug report, review tab, connector and MCP settings, memory, model and skill settings, trigger input, version history, Space resource editor) still use the default, enhanced or outlined styles.
• Combined type-check, i18n, design-token/CSS checks and focused lint/format checks passed. This was a feature-scoped retest, not the full matrix. Broader approval scopes, failed approval decision, touch/language and full theme coverage remain unverified.