Fix preview wheel zoom scale updates

[Diyoncrz18]

Fixes #3626

Why

I am opening this PR to close the design preview zoom bug reported in #3626. While using an HTML design preview, scrolling the mouse wheel over the preview at 100% did not change the toolbar value or the preview transform, so the preview stayed at scale(1).

The pain being addressed is user-facing: wheel zoom appeared to be available on the preview surface, but it did not update the same zoom state used by the toolbar dropdown and the preview frame scale.

What users will see

Scrolling the mouse wheel over an HTML design preview now changes the preview zoom:

• wheel-up increases zoom, for example from 100% to 125%
• wheel-down decreases zoom, for example from 125% to 100%
• Ctrl+wheel follows the same preview zoom behavior
• the toolbar zoom label updates with the new value
• the preview frame transform updates to the matching scale

Draw/Mark mode keeps its existing wheel behavior for scrolling the preview iframe instead of changing preview zoom.

Surface area

• UI - new page / dialog / panel / menu item / setting / empty state in apps/web or apps/desktop (including Electron menu bar)
• Keyboard shortcut - new or changed
• CLI / env var - new od subcommand or flag, new tools-dev / tools-pack / tools-pr flag, or new OD_* env var
• API / contract - new /api/* endpoint, new SSE event, or changed shape in packages/contracts
• Extension point - new entry under skills/, design-systems/, design-templates/, or craft/, or change to the skills protocol
• i18n keys - added new translation keys (see TRANSLATIONS.md for the locale workflow)
• New top-level dependency - adding any new entry to the root package.json (dependencies or devDependencies); workspace-package package.json files are out of scope. Include a paragraph on what we get vs. what bytes we ship (see CONTRIBUTING.md -> Code style)
• Default behavior change - changes what existing users experience without opting in (default model, default setting, file/SQLite schema, auto-network on startup, auto-install)
• None - internal refactor, docs, tests, or translation update only

Screenshots

Not attached. This is an interaction-only bug fix with no layout or visual style change; the entry point is the existing design preview zoom control. Regression tests cover the toolbar label and preview transform updates after wheel zoom.

Bug fix verification

• Test path that reproduces the bug: apps/web/tests/components/FileViewer.test.tsx
• Did the test go red on main and green on this branch? yes. The new focused test fails before the source change because wheel-up leaves the zoom button at 100%; it passes after the fix.
• Additional coverage:
  • apps/web/tests/runtime/srcdoc.test.ts
  • apps/daemon/tests/project-file-range.test.ts

Validation

• corepack pnpm exec vitest run -c vitest.config.ts tests/components/FileViewer.test.tsx -t "preview zoom|Draw overlay wheel" from apps/web
• corepack pnpm exec vitest run -c vitest.config.ts tests/runtime/srcdoc.test.ts from apps/web
• corepack pnpm exec vitest run -c vitest.config.ts tests/project-file-range.test.ts -t "injects the URL preview scroll bridge only when requested" from apps/daemon
• corepack pnpm --filter @open-design/web typecheck
• corepack pnpm --filter @open-design/contracts build
• corepack pnpm --filter @open-design/registry-protocol build
• corepack pnpm --filter @open-design/daemon exec tsc -p tsconfig.json --noEmit
• corepack pnpm --filter @open-design/daemon exec tsc -p tsconfig.tests.json --noEmit
• corepack pnpm guard
• git diff --check HEAD

[lefarcen]

Thanks @Diyoncrz18 — the narrowed bug write-up and the red→green test seam are both clear here. I've queued maintainer review, and because this changes preview behavior it’ll also need a manual QA pass before merge, so please hold off self-merging for now; we’ll loop that in once the PR is merge-ready.

[github-actions]

Visual regression review

Head: 83dd07a · Base: 59311ce

1 changed · 52 unchanged · 0 new without baseline · 0 failed

Changed cases

Case	Main	PR	Diff
visual-integrations-use-everywhere 8,029 px (0.62%)

Unchanged cases

Case	Main	PR	Diff
visual-avatar-local-agent-list 0 px (0.00%)
visual-avatar-local-agent-list-panel 0 px (0.00%)
visual-avatar-menu 0 px (0.00%)
visual-avatar-menu-panel 0 px (0.00%)
visual-avatar-open-design-account 0 px (0.00%)
visual-critical-settings 0 px (0.00%)
visual-critical-workspace 0 px (0.00%)
visual-critical-workspace-preview 0 px (0.00%)
visual-design-system-detail 0 px (0.00%)
visual-design-systems 0 px (0.00%)
visual-home 248 px (0.02%)
visual-home-catalog 0 px (0.00%)
visual-home-context-picker 0 px (0.00%)
visual-home-context-picker-popover 0 px (0.00%)
visual-home-plugin-filter 0 px (0.00%)
visual-home-plugin-use-staged 0 px (0.00%)
visual-home-plugin-use-with-query 0 px (0.00%)
visual-home-staged-attachment 0 px (0.00%)
visual-integrations 0 px (0.00%)
visual-integrations-mcp 0 px (0.00%)

Visual diff is advisory only and does not block merging.

[mrcfps]

@Diyoncrz18 I reviewed the wheel-zoom path across the HTML preview viewer, the injected srcdoc/URL preview bridges, and the added regression coverage. The change reuses the existing zoom presets, keeps iframe-origin messages constrained to the active preview frame, and preserves Draw overlay wheel behavior by avoiding zoom updates while the draw overlay is open. I also checked the scoped daemon bridge injection update and the focused test additions; I could not run the Vitest commands locally because this prepared checkout has no installed node_modules, but the patch itself looks sound. Thanks for tightening this user-facing preview interaction and for including focused coverage.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[AmyShang-alt]

Thanks @Diyoncrz18 for taking a fresh pass on this and for adding focused coverage around the preview zoom path.

We rechecked the current production build and can no longer reproduce the original issue from #3626 there. Linking this PR with the issue for tracking, and we'll use that updated repro status when deciding whether a code change is still needed here.

Related issue: #3626

[AmyShang-alt]

Closing this PR because the original linked issue (#3626) can no longer be reproduced on the current production build, so we are not taking this implementation as-is. Thanks again for the focused tests and investigation here.