Add a thinking-level (reasoning effort) picker to the chat composer

[DragonnZhang]

Closes #44

What & why

Comparable desktop apps let you dial reasoning effort right from the composer —
Claude Code Desktop ships a dedicated effort menu (⌘⇧E) next to its model
menu. OpenWork supports six per-session thinking levels (off / low /
medium / high / xhigh / max) but had no way to change the level from the
chat composer — the only control was Settings → AI, which sets a per-workspace
default for new chats. Raising effort for a single hard task meant leaving the
conversation, editing settings, and starting over.

The composer already had the neighbor for it (the model picker), and the
plumbing was already in place: thinkingLevel / onThinkingLevelChange are
threaded from ChatPage / DraftChatPage → ChatDisplay → ChatInputZone →
InputContainer → FreeFormInput, and both pages already persist the value. Only
the UI trigger was missing.

This adds a thinking-level picker to the composer toolbar, immediately before
the model picker and mirroring it:

• a toolbar button showing the current level's name with a brain icon + chevron
  (tooltip "Thinking"),
• opening it lists all six levels (name + description) with a check on the active
  level, and on select calls the already-wired onThinkingLevelChange(level) — so
  the choice persists exactly like a model change,
• hidden in compactMode (same rule the model picker uses).

Frontend-only. It renders a Radix dropdown (the same StyledDropdownMenu*
primitives the model picker uses) and calls the existing onThinkingLevelChange
prop — the value already flows to the runtime today, so there is no backend /
qwen-code change. No new i18n keys: level names/descriptions reuse the existing
thinking.* keys and the trigger tooltip reuses settings.ai.thinking.

Changes

• components/app-shell/input/FreeFormInput.tsx — the thinking-level dropdown
  (new thinkingDropdownOpen state; destructure the previously-unused
  onThinkingLevelChange prop; render the picker from THINKING_LEVELS).
• e2e/assertions/thinking-level-picker.assert.ts — new CDP assertion (below).

Verification

• bun run typecheck:all — introduces no new errors. Delta vs main is
  zero; the only errors are the same pre-existing ones unrelated to this change
  (auto-update.ts, a settings-default-thinking test tuple, and two test files
  importing vitest). None are in the file this PR touches.
• bun test — identical to main: 3578 pass / 56 fail on both this
  branch and main in the same environment (the 56 failures are pre-existing:
  BrowserCDP, pet/RPC registration profiles, i18n sorted-parity checks, etc.).
  This change adds zero new failures.
• bun run lint:i18n:parity — OK (6 locales, 1542 keys each). No new keys.
• Renderer build (bun run build:renderer, where this change lives) — ✅ builds
  cleanly.

CDP e2e assertion (thinking-level-picker.assert.ts)

The assertion drives the real built app over CDP: it waits for the ready AppShell,
asserts the composer renders the thinking-level trigger, opens the menu and asserts
all six levels are listed with exactly one marked selected (matching the trigger
label), then selects a different level and asserts the menu closes and the
trigger label updates to the chosen level — proving the picker actually changes
the session's thinking level, not merely displays a list.

⚠️ Local CDP run was blocked by this sandbox's egress policy, not by the
feature. The Electron binary download and the libsignal GitHub dependency
(pulled in transitively by the WhatsApp/Baileys worker that electron:build
bundles) both return 403 from the egress proxy, so the app can't be built or
launched here. The assertion is included so CI / a reviewer can run
bun run e2e in an environment with normal network access. Everything that does
not require launching Electron (typecheck, unit tests, i18n parity, renderer
build) passes with zero delta vs main.

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