fix(toolpath-desktop): fall back to transform:scale when CSS zoom unsupported

[eliothedeman]

Summary

• The graph-view zoom in Preview.svelte applied the non-standard zoom property inline on .graph-zoom. It works in every Tauri runtime we ship against (WebKit on macOS, Chromium WebView2 on Windows/Linux), but breaks in non-WebKit/Chromium engines (Firefox dev testing, bun run dev hit from a plain browser): the visual scales while the scroll container sees unscaled dims, so scrollbars go wrong.
• Switched the inline style to a --pg-zoom custom property and moved the zoom declaration into the stylesheet, then added an @supports not (zoom: 2) block that falls back to transform: scale with inverse-compensated width/height.
• .path-graph inside the wrapper already has explicit px dims from dagre, so the wrapper-level calc(100% / var(--pg-zoom)) trick is sufficient — no viz.ts plumbing needed, per the minimal-fix guidance in the issue.

Test plan

• bun run check — 0 errors (4 pre-existing a11y warnings in BrowseClaude/BrowsePi, unrelated).
• bun run build — Vite build succeeds.
• Manual: in Tauri WebKit the graph zooms as before and scrollbars track content bounds.
• Manual: in Firefox (bun run dev on localhost:1420) the fallback kicks in, visuals scale, and scrollbars match.

Closes #37

[github-actions]

🔍 Preview deployed: https://2ca86d45.toolpath.pages.dev

[eliothedeman]

Summary

Yes — this implements the fix from #37 faithfully: the inline zoom: {level} is replaced with a --pg-zoom custom property, and an @supports not (zoom: 2) block in styles.css provides the transform: scale fallback with inverse-compensated width/height.

Notes

• Preview.svelte:250 — style="--pg-zoom: {zoom}" on .graph-zoom is the right shape; canvasEl binding and surrounding scroll container are untouched, so WebKit/Chromium behavior is preserved (they take the zoom: var(--pg-zoom, 1) path in the stylesheet).
• styles.css:705-720 — fallback matches the issue's recipe exactly: transform-origin: 0 0 (top-left pin so scroll offsets behave), plus width/height: calc(100% / var(--pg-zoom, 1)) to expand the wrapper since transform doesn't reflow. The concern from the issue about needing viz.ts plumbing is correctly sidestepped: .path-graph already gets explicit px dims from dagre, so 100% / zoom on the wrapper is sufficient.
• @supports not (zoom: 2) is the correct detection idiom — the : 2 value forces it to be a real feature query. Firefox returns false here and takes the fallback; WebKit/Chromium skip it.
• No scope creep: two files touched, no version bumps, no dependency changes, no viz.ts edits. Comments preserve the rationale from the original inline comment and explain why the fallback works.
• No interaction risk with dagre-d3: the fallback only kicks in when zoom is unsupported, and dagre computes layout in pixel space before either path applies — the transform just rescales what's already laid out.

Verdict

LGTM — minimal, correct, matches the issue spec verbatim. (Couldn't formally approve since it's my own PR.)