Keep workspace geometry at native scale

[hamzamerzic]

Summary

Desktop density used a document-wide 90% root zoom. That created two coordinate systems: pointer events and frame bounds arrived in painted client pixels, while workspace layout, transforms, fixed menus, iframe actionability, and scroll geometry consumed layout pixels. Each interaction then needed a scale bridge, and browser tests needed a direct DOM-click bypass for controls inside frames.

The shell now remains at native document scale. Density still comes from the compact rail and reduced chrome, while viewport, pointer, iframe, menu, and layout geometry share one coordinate system.

Changes

• remove desktop root zoom and its tab-font compensation
• simplify drawer resize, pinned reordering, pane dividers, workspace dragging, and context-menu placement to native client/local translation
• delete the frame-click actionability bypass and restore physical Playwright clicks
• stabilize empty app/chat query lists and ratchet lint warnings from 64 to 47
• update the geometry contracts around the single native coordinate space

#434 deliberately preserved 90% density during the broader maintenance reconciliation. This PR revisits that choice because the compensating geometry and test bypasses became recurring maintenance weight. #458 separately owns the deeper reader/spacer/streaming state machine; this change deliberately does not duplicate or modify that work.

Testing

• 2,233 frontend library tests and 76 hook tests passed after rebasing on current main
• lint passed at the 47-warning ratchet
• production and PWA builds passed
• privacy-path checks and git diff --check passed

[hamzamerzic]

Review synthesis

Verdict: approve with one thing to check first — a genuinely good deletion; one behavioural consequence is worth confirming deliberately rather than discovering later.

Removing :root { zoom: 0.9 } and, with it, the entire painted-vs-layout coordinate bridge — clientDeltaToLocal, the layoutViewport scale in placeContextMenu, the Playwright DOM-click workaround — is the right kind of change: −242 lines, one coordinate space, and every reviewed caller consistent with it. This is the sort of simplification that makes the next change cheaper.

[MAJOR] Pane capability thresholds now sit right on the default desktop configuration

Where: Shell.css:609 (removed zoom); thresholds at paneModel.js:34-38, consumed via modeForRect → projectLayout

contentRect comes from el.clientWidth/clientHeight, which under CSS zoom returns layout pixels — the codebase says so itself at useWorkspaceDrag.js:139-142. With zoom: 0.9 a 1280px viewport gave the shell 1422 layout px; at native scale it gives 1280. WIDE_MIN_W = 960 / WIDE_MIN_H = 600 are unchanged, so every window now needs roughly 11% more real width and height to afford wide.

Failure: a laptop that previously tiled a chat beside its app now falls back to a narrower mode at the same window size — the workspace behaves differently after an upgrade with no setting changed. That is a real product change, not a rendering detail.

Fix: either scale the thresholds by the same factor the zoom was providing (≈0.9) so behaviour is preserved, or state in the PR body that the affordance boundary is deliberately moving and this is the intended new geometry. Both are defensible; silently shifting it is the one option that is not.

Smaller items

• The contract test now forbids the divider drag from reusing the shared translation helper — it asserts the absence of a call, so a future correct refactor that reuses the helper fails CI for no behavioural reason.
• Two assertions pin comment prose, so rewording a comment breaks the build.

---

_{Two independent model reviews (Claude Opus 5, GPT-5.6 Sol) run against this exact head with no shared context, then synthesized. The second cleared it outright; the threshold shift is the difference between the two reads and is easy to confirm directly.}

[hamzamerzic]

Follow-up on my own major — I went to fix it and concluded I was half-wrong.

The arithmetic holds: with zoom: 0.9 (base Shell.css:619) a 1280 device-px window reported ~1422 CSS px, so WIDE_MIN_W = 960 sat at ~864 device px. At native scale it sits at 960 device px, so windows between roughly 864 and 960 px wide lose wide.

But calling that a regression was the wrong framing. The zoom was shrinking content 10%; at native scale a 900 px window genuinely has less usable room for two panes than it did when everything was 10% smaller. The thresholds are in CSS pixels and they still mean what they say — the affordance boundary tracking real space is arguably the correct outcome of removing the zoom, not a side effect to compensate for.

So I'm not proposing a constant change, and I'm not touching it. Two things still worth a moment:

• If you did intend the boundary to stay where it was, scaling the four constants by 0.9 (960/600/700/520 → 864/540/630/468) restores it — but paneModel.test.js:590 pins those numbers, so the test moves with them.
• Either way it's worth one line in the PR body, because the change is invisible in the diff and someone will eventually notice their laptop stopped tiling.

The two smaller notes from my review stand: the contract test now forbids the divider drag from reusing the shared translation helper, and two assertions pin comment prose.

No objection to this merging.