Problem

When a pane is zoomed, the non-active pane (bottom pane in horizontal split, right pane in vertical split) would appear visually shifted by a few pixels in height/width. The border highlight and cursor position of the zoomed pane were also slightly misaligned.

Root Cause

Two separate but related issues:

1. Client-side (src/client.rs)
   compute_active_rect_json was used to compute active_rect for border highlighting and cursor positioning. This function internally calls split_with_gaps, which subtracts 1px gap per separator and returns child rects with offsets applied. However, when a pane is zoomed, the renderer passes the full content_chunk area to the child — ignoring gaps. The mismatch between what the renderer drew and what active_rect computed caused the visual shift.
2. Server-side (src/tree.rs)
   In resize_all_panes, when a pane is zoomed, the PTY was being resized to the gap-reduced rect instead of the full viewport area. This meant the zoomed pane's PTY dimensions didn't match what was actually rendered on screen.

Solution

src/client.rs — Replace compute_active_rect_json with the zoom-aware variant:

// Before
let active_rect = compute_active_rect_json(&root, content_chunk);

// After
let active_rect = compute_active_rect_json_zoom_aware(&root, content_chunk, state.zoomed);

When state.zoomed is set, compute_active_rect_json_zoom_aware returns the full content_chunk directly, matching what the renderer actually uses.

src/tree.rs — In resize_all_panes, when win.zoom_saved.is_some(), override the active pane's rect to the full area before sending the PTY resize signal, so the zoomed pane gets the correct full-viewport dimensions.

Impact

• Zoomed pane now fills the full viewport with correct PTY dimensions
• Border highlight and cursor position align correctly when zoomed
• No regression to normal (non-zoomed) split behavior — the zoom-aware path only activates when state.zoomed is set