feat(Viewer): add zoom/pan and rotate to image viewer

[vladopol]

This is a reworked resubmission of #1756, which was rightfully closed — the previous version shipped with functional defects that testing should have caught. This version has been verified: every scenario from the #1756 review was reproduced against the old code, fixed, covered by an automated test, and additionally checked by hand in the dev app.

Closes #1535 (zoom), closes #1757 (rotate)

Root causes of the #1756 defects

All five reported problems traced back to two causes:

1. The custom clampToBounds() was broken by design. It clamped the full-size wrapper instead of the image, so a letterboxed image could be panned almost entirely off-screen. Worse, it called moveTo() from inside the 'pan' event handler — moveTo() synchronously re-fires 'pan', and since getBoundingClientRect() returns pre-repaint geometry inside that cascade, the correction never converged: unbounded recursion (the freeze @Antreesy hit).
2. panzoom's smooth zoom never reaches its target: amator computes the final t=1 frame but never calls step() for it, so zooming out settles at scale ≈ 1.002–1.007 instead of 1. Combined with strict scale === 1 checks this left the viewer in the "neither pan nor zoom works" state @ShGKme found after the second double-click.

What changed

• Bounds are computed from the image's fit box using layout values only (offsetWidth/clientWidth — unaffected by CSS transforms, so never stale mid-animation). Per axis: the image stays centered while it fits the container, and its edges never move inside the container edges once it exceeds it.
• The clamp mutates panzoom's transform model in place inside the event handlers — applied with the already-scheduled repaint, cannot re-trigger events, no recursion possible.
• All fit-state checks use an epsilon; the scale snaps to exactly 1 on zoomend.
• Zoom-out now re-centers the image on every animation frame (the conflicting smoothMoveTo(0, 0) is gone), so it smoothly returns to fit regardless of where you double-click.
• Rotating by 90°/270° applies a fit compensation so landscape images don't overflow the container; container resizes re-measure and re-clamp.

Why not native bounds: true (@Antreesy's question): panzoom's built-in bounds track the transformed element — here the full-size wrapper, not the letterboxed image inside it, so they allow exactly the "image pans out of view" bug. Attaching panzoom directly to the <img> doesn't work either: the DOM controller's bbox assumes the element sits at the owner's top-left, which breaks flex centering, and boundsPadding: 1 pins a letterboxed image to a corner. A custom clamp is required; it just has to be written against the transform model instead of live DOM rects.

How it was tested

• Automated: a Playwright harness replicating the component's exact DOM/CSS/logic drives real mouse interactions. Each review scenario from feat(Viewer): add zoom/pan and rotate to image viewer #1756 (pan-out-of-viewport, boundary freeze, off-center zoom-out displacement, dead-interaction state, wrong pan boundary) reproduces against the old logic and passes with this one, plus 13 edge cases: letterboxed portrait/landscape/small images, five consecutive zoom cycles, wheel zoom to 8× and back at a corner, rotate + zoom + pan combinations, container resize while zoomed, and a stress drag/zoom run with zero errors.
• Manual: all of the above exercised by hand in the running app (macOS).

AI-assisted, per the AI policy: label + Assisted-by trailers. All changes reviewed and manually verified by the author.