Bug: Slideshow Control cannot change zoom

[bewuwy]

The slideshow animations cannot modify zoom currently. (It might be a ViewBox issue?)

They should be able to do so.

[bewuwy]

This was generated by AI during triage.

Human Brief

Category: enhancement (functionally a missing capability, though titled "Bug")
State: ready-for-human
Why not an AFK agent: touches the core 2D camera architecture (d3-zoom transform, user-interaction coexistence, split canvas, activity gating) and the acceptance test is visual/perceptual — the zoom easing has to look right. Needs a human eyeballing it live, not just green unit tests.

Summary: Slideshow animations cannot change the 2D camera zoom or position. Give slideshow steps a channel to drive the camera, eased smoothly, without breaking user pan/zoom.

Current behavior:
SlideShow animates a generic applet State via pure step functions (t, state) => { state, labelNext, labelPrev }, interpolated over timeSteps. That state drives primitives but has no connection to the canvas camera. In CanvasD3, cameraZoom/cameraPosition are seeded once (from ViewBox or props) into init-only local values and thereafter the camera is driven purely by d3-zoom on the SVG. There is no reactive or imperative path to change zoom/position after mount (only the internal reset() moves it, back to default). So a slideshow step cannot reach the camera — the reporter's guess about ViewBox is half-right: ViewBox only sets the initial zoom.

Desired behavior:
A slideshow (and any applet) can move the 2D camera by setting target zoom/position, and the canvas eases to that target.

• Channel: Canvas2D/CanvasD3 cameraZoom and cameraPosition become reactive targets. When they change after mount, the canvas animates to the new transform. No change to the generic SlideShow contract — an applet author includes camera fields in their own State and binds these props to them; a step that wants to move the camera returns new target values.
• Easing owned by the canvas: on a target change, run a d3 transition using d3.interpolateZoom (correct joint pan+zoom perceptual easing), not the slideshow's linear per-tick interpolation. The step sets a target once; the canvas eases.
• Single source of truth: apply the move through d3's own zoom.transform (the pattern reset() already uses: selection.call(zoomBehavior.transform, zoomIdentity.translate(px,py).scale(k))), so after the eased move a user pan/zoom continues from the new transform with no jump/snap-back.
• Both axes: zoom and position.
• No-pan canvases (enablePan=false): programmatic zoom and position still apply (user pan stays disabled). enablePan gates user interaction only, not programmatic control — the no-pan render path must apply a programmatic translate too, not just scale().
• Gating: programmatic moves bypass activityState (advancing a slideshow is an explicit panel action); user wheel/drag stays gated as today.
• Clamp: programmatic zoom target is clamped to the existing scaleExtent ([cameraZoom/6, 6/cameraZoom]), from one tunable spot.
• Camera-state sync: feed programmatic moves into the same debounced cameraState.camera2D update user zoom uses, so legend/labels/URL zoom stay consistent.

Key interfaces:

• CanvasD3 cameraZoom: number and cameraPosition: Vector2 props — currently init-only locals; must become reactive targets that trigger an eased d3-transform move on post-mount change.
• The d3 zoom behavior / transformScene path — programmatic moves route through zoom.transform; the no-pan branch must honor a programmatic translate.
• SlideShow state contract — unchanged; camera targets live in the applet's own State.
• One example applet wired up to prove the path (a slideshow step that zooms/pans).

Acceptance criteria:

• A slideshow step that changes target zoom animates the 2D camera smoothly (perceptual interpolateZoom easing, no linear jank).
• Same for target position (pan), including panning while zooming.
• After a programmatic move, user pan/zoom continues from the new transform with no jump.
• Works in enablePan=false canvases for both zoom and position; user pan remains disabled there.
• Programmatic zoom is clamped to scaleExtent.
• prev/reverse and reset restore the prior camera (targets ride the snapshotted state).
• Existing applets that never set camera targets behave exactly as before; no animation fires on initial mount.
• Legend/axis-labels/URL zoom stay in sync after a programmatic move.

Out of scope:

• 3D slideshow camera control (Canvas3D/Threlte) — separate follow-up.
• Changing the generic SlideShow step signature.
• New imperative camera API (rejected in favor of the reactive-prop channel).
• Reworking reset() beyond reusing its transform-application pattern.

Design rationale (recorded): Chose reactive-prop channel over an imperative animateTo because slideshow steps are pure (t,state) functions with no canvas handle and their own interpolation loop — an imperative API would need a canvas ref plumbed into every step and would run a second, desyncing animation clock. The one real advantage of the imperative route (proper zoom easing) is recovered by having the canvas own an interpolateZoom transition on prop change.

[bewuwy]

This was generated by AI during triage.

3D slideshow camera control tracked separately as #493 (out of scope here).