Add wide preview control to Desktop

[seagpt]

Summary

• Raises the Hermes Desktop preview rail max width so website previews can be stretched close to full-window width (90vw instead of the old 38rem cap).
• Adds a preview titlebar action that toggles Maximize preview width / Restore preview width; the maximize preset now targets 90% of the viewport while leaving a small chat column visible.
• Keeps the existing preview console and DevTools titlebar actions intact.
• Moves the new titlebar labels into the Desktop i18n dictionaries instead of hardcoding English in the component.

Why

Desktop capped the preview rail at 38rem, and even the first wide-preview preset could still feel constrained on large screens. Website/browser QA needs a Codex-style wide working surface where the preview can occupy most of the window while the chat remains available for steering.

Validation

Ran from the repo root:

npm ci
npm --workspace apps/desktop run test:ui -- src/app/chat/right-rail/preview-pane.test.tsx
npm --workspace apps/desktop run typecheck
npm --workspace apps/desktop run lint
npm --workspace apps/desktop run build
python scripts/check-windows-footguns.py $(git diff --name-only origin/main...HEAD)

Notes:

• Targeted preview-pane tests: 3 passed.
• Desktop lint passes with one pre-existing warning in apps/desktop/src/app/settings/model-settings.tsx about setConfig hook deps.
• Build passes; Vite still emits pre-existing CSS/barrel/chunk-size warnings.

[alt-glitch]

This was generated by AI during triage.

Related: #40494 (feature request), #40511 (open PR that loosens the static width caps 38rem->72rem). This PR pursues the same goal (wider Desktop preview rail) via a different mechanism — an interactive Widen preview/Restore preview width titlebar toggle plus raising the cap to 72vw. Flagging the cluster so a maintainer can pick one approach; not a duplicate.

[seagpt]

Yep, looks like it has the same intention.

[teknium1]

Thanks for the focused Desktop control and for adding all Desktop locale entries. The current 38rem cap remains on main (apps/desktop/src/app/chat/right-rail/preview.tsx:39), so the underlying request is still valid.

Problems

• widePreviewWidth() reserves only 160px for chat (apps/desktop/src/app/chat/right-rail/preview-pane.tsx:128 in this PR). Current Desktop defines --chat-min-width: 28rem (apps/desktop/src/styles.css:386), and the normal preview sizing formula also subtracts sidebar and file-browser tracks (apps/desktop/src/app/chat/right-rail/preview.tsx:43-47).
• The programmatic width override is installed directly as a PaneShell grid track (apps/desktop/src/components/pane-shell/pane-shell.tsx:226-228); the Pane's min/max bounds are applied only by pointer dragging (apps/desktop/src/components/pane-shell/pane-shell.tsx:440-451). At the test's 1600px viewport, the asserted 1440px preview can therefore leave less than the chat minimum.

Suggested changes

• Bound the preset by the same available-width calculation that protects chat, or make PaneShell clamp programmatic overrides too.
• Add coverage with the sidebar and file browser open, asserting the chat minimum remains available.

Automated hermes-sweeper review.

[teknium1]

This 160px reserve bypasses the existing --chat-min-width: 28rem contract and ignores sidebar/file-browser tracks. setPaneWidthOverride() becomes the grid track directly; PaneShell only clamps min/max during pointer dragging. Please bound this preset by the actual available rail width so maximizing cannot collapse the chat column.