Problem or Motivation

OpenWork's chat composer (FreeFormInput) auto-grows as you type, but only up to
a fixed cap — min(66% of window height, 540px). There is no way to
deliberately give the input a large editing area. When drafting or editing a long
prompt (a spec, a big paste, a multi-paragraph instruction), you're stuck writing
and scrolling inside a small box even when the window has plenty of room.

Comparable desktop chat surfaces (Claude's desktop app, ChatGPT desktop, Codex
desktop) all offer a maximize / expand affordance on the composer so you can
pop the input open into a tall editor for composing long messages, then collapse
it back. OpenWork is the conspicuous exception: the composer toolbar already has a
model picker, a thinking-level picker, a context-usage indicator and an attach
control, but no expand toggle.

Proposed Solution

Add an expand / collapse toggle to the composer toolbar (right-side controls,
next to the thinking-level and model pickers, mirroring their !compactMode
rule):

• A small icon button (Maximize when collapsed, Minimize when expanded) with a
  tooltip ("Expand composer" / "Collapse composer") and aria-pressed reflecting
  the state.
• Clicking it maximizes the input to a large share of the window
  (max(78% of window height, 560px), recomputed on resize) by applying a tall
  minHeight/maxHeight to the editable area, so the box is genuinely large even
  when empty.
• Clicking again collapses it back to the normal auto-grow cap.
• The maximized state resets when switching sessions, so a new conversation always
  starts compact.

This is a frontend-only change:

• It only adjusts the renderer's local layout state (isComposerExpanded) and the
  inline height style already applied to the RichTextInput. No backend / no
  qwen-code change.
• Two new i18n keys (chat.expandComposer, chat.collapseComposer) added to all
  locales for the tooltip.

Alternatives Considered

• Auto-grow only (the status quo) helps for moderate text but caps out; it
  can't be opened deliberately for long-form composing, and never exceeds ~540px.
• A separate full-screen editor modal would be heavier and diverge from the
  established composer-toolbar pattern (model/thinking pickers) that this mirrors.
  An inline maximize is the lighter, more discoverable fit and can be layered with
  a modal later if wanted.

Additional Context

Feasibility: frontend-only / doable. Verified against apps/electron — the
composer already owns its height state (inputMaxHeight, computed from the window
in a resize effect) and passes an inline style (merged onto the contenteditable)
to RichTextInput; the toggle just introduces a second, larger height and swaps
which one is applied.

Acceptance criteria (CDP e2e assertion)

A new e2e/assertions/composer-expand.assert.ts drives the real built app over
CDP entirely in the draft (no-session) state — no seeded conversation needed:

1. The composer renders the expand toggle, initially aria-pressed="false".
2. Measure the input area's height (collapsed).
3. Click the toggle → the input grows substantially (height >= 2× the
   collapsed height) and the toggle flips to aria-pressed="true".
4. Click again → the input collapses back to roughly its start height and
   the toggle returns to aria-pressed="false".

The height measurements prove the toggle actually resizes the composer, not
merely swaps an icon.

Part of the autonomous desktop-feature loop (loop-bot).