feat(web): opt-in full-width side panels

[aliguy]

What Changed

Adds an off-by-default Full-width panels setting under Settings > Behavior > Panels.

When it is on:

• the right dock opens at the full width of the chat shell instead of an even 50/50 split
• the right dock and split-pane panels can be dragged all the way to the edge of their row, collapsing the chat column out of view
• panes with a natural size (the phone-shaped device pane) keep their preferred width, since stretching a fixed-aspect surface only adds empty space around it

When it is off, behavior is exactly what it is today.

The width math moved into a new pure module, apps/web/src/lib/panelWidthPolicy.ts, so RightDock and SplitChatSurface share one testable source of truth instead of each carrying its own arithmetic inline.

Why

Panel width is currently bounded by canComposerHandlePanelWidth in apps/web/src/lib/panelResize.ts. Every resize drag on the right dock and on split-pane panels runs that probe, and the drag is rejected as soon as the chat composer would overflow its viewport or fall under COMPOSER_COMPACT_MIN_LEFT_CONTROLS_WIDTH_PX. In practice a panel tops out near half the window, and there is no affordance to go past it.

That default is right for a diff you are reading alongside the conversation. It is wrong for the embedded browser, which is the surface people most want to hand the whole window to. Real sites assume a desktop viewport, so at roughly half a laptop screen sign-in flows and dense app UIs end up cramped, wrap badly, and push controls out of reach, with no maximize control to escape it. Google sign-in pages are the case that prompted this: comfortable at full width, awkward at half.

The fix keeps the safe default and gives the user an explicit way out of it. A setting rather than a new default, because the clamp exists for a good reason and most panels should keep it.

Scope note

This changes how wide a panel is allowed to be. It does not change how BrowserPanel renders inside the panel, does not add an OS-level fullscreen mode for the webview, and does not touch scrolling inside the embedded page. If any of those are separate defects, happy to file them separately rather than fold them in here.

UI Changes

No screenshots attached, and I would rather say so than pad the PR: I could not get reliable before/after captures of the drag out of my dev environment. Happy to add them if that blocks review. The visible differences are:

1. A new row in Settings > Behavior, in a new "Panels" section above "Review", titled "Full-width panels", using the shared renderBooleanSettingRow switch plus its reset affordance. It is also indexed in settings search under behavior:full-width-panels.
2. With the setting on, opening the right dock puts its inner edge flush with the edge of the chat row instead of halfway across, and the resize handle drags to that same edge.
3. With the setting off, nothing changes.

Verification

• bun run typecheck: 7/7 tasks pass, 0 errors
• oxfmt: clean
• oxlint: 0 errors (433 pre-existing warnings, count unchanged)
• bun run test:web:focused src/lib/panelWidthPolicy.test.ts: 12/12 pass
• Full apps/web suite: 3970 passed, 6 failed. All 6 are "test timed out" in src/components/ChatMarkdown.test.tsx and src/components/Sidebar.import.test.ts on a slow Windows box. I re-ran both files with apps/web/src reverted to unmodified origin/main in the same checkout and they fail identically, so they are not from this change.

Checklist

• This PR is small and focused (8 files, +245 / -8, one new module plus its test)
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes