Preview workspace slice 4 — pane-scoped controls and focused-pane chrome #945

Acceptance Criteria

• Each leaf pane has its own stored zoom value, initially inheriting the source pane's value when the leaf is created.
• Changing zoom in one visible pane does not change any other pane's zoom.
• Existing zoom controls, wheel/pinch zoom behavior, and category-aware effective zoom continue to run through the baseline renderer path.
• A renderer host moved to another pane adopts the destination pane's zoom value without recreation, document replacement, focus loss, or scroll restoration.
• Markdown preview/edit mode remains renderer-owned and file-local. This slice does not create a pane-level mode store or duplicate an existing mode value.
• The focused pane has a clear non-disruptive visual indicator. Clicking its tab strip or content, completing an open, or completing a successful transfer/split updates that indicator through Preview workspace slice 3 — drag-first pane tree and renderer relocation #944's focused-pane route.
• Dirty indicators and close controls appear correctly in every leaf tab strip using Preview workspace slice 2 — persistent renderer pool and inner tabs #943's dirty boolean and close behavior.
• Hidden inactive renderer hosts do not expose interactive controls or receive pointer input.
• The focused-pane indicator and controls do not move editor focus to the composer or alter renderer scroll state.
• Browser tests prove two panes can hold different zoom values, a moved renderer adopts the destination value while retaining identity and content, and focused-pane chrome tracks actual pane targeting.

Key Decisions

Zoom belongs to a pane; mode belongs to a renderer. Zoom describes the viewport into a leaf pane. Preview/edit mode describes the individual file renderer currently shown there. Keeping those scopes separate avoids turning renderer-owned state into workspace data.

This is control wiring, not a control rewrite. The existing Preview renderer remains responsible for its controls' rendering, wheel behavior, and category semantics. The workspace supplies the pane-local zoom accessor and does not import or reimplement CodeMirror behavior.

Focused-pane chrome is observational. It communicates routing state but does not steal focus, mutate a document, or create a second active-editor model.

Testing Decisions

Extend the real-browser suite with a two-pane fixture that verifies:

• independent zoom values remain independent after repeated tab changes;
• a transfer relocates the same renderer host and applies destination-pane zoom;
• Markdown edit mode remains local to the renderer across pane targeting;
• clicking panes, splitting, and transferring updates visual focused-pane chrome;
• controls and chrome do not move focus from a visible CodeMirror editor or reset its local scroll.

Unit tests may cover pane-zoom selection and inheritance. Browser tests remain authoritative for renderer identity, control wiring, and focus behavior.

Constraints And Invariants

• This issue does not modify PreviewFileView or PreviewEditor unless a Preview workspace slice 1 — baseline renderer interaction contract #942 interaction regression proves the existing renderer contract cannot accept a pane-local zoom accessor.
• No pane stores file content, draft text, editor selection, document scroll, or preview/edit mode.
• The eight-tab limit and dirty-close behavior remain owned by Preview workspace slice 2 — persistent renderer pool and inner tabs #943.
• Breadcrumb navigation remains the final feature slice after these controls are proven.

Source

Part of #940 and ADR 0013. Blocked by #942, #943, and #944. Replaces this issue's former nested-DnD implementation plan; DnD is owned by #944.