perf: frame-limit viewport gesture publication

[dompm]

Summary

• coalesce wheel, pan, and pinch viewport publication to animation frames
• retain immediate mutable viewport values for event-to-event accumulation
• cancel pending viewport work on unmount

Why

Trackpads and touch devices can emit multiple viewport events per display frame. Coalescing their React publication reduces redundant panel work.

Stack

Depends on #125 (codex/interaction-pen-pencil).

Verification

• interaction test suite passes
• production build succeeds
• no new TypeScript errors beyond the documented baseline

This is a draft pending performance review and browser regression testing.

[dompm]

This coalesces raw viewport events, but it is only the first half of the planned viewport phase.

• [P1] Do not publish high-frequency viewport state through the owning panel. scheduleViewport still calls setZoom and setPan, so ResultPanel or SheetPanel rerenders in full on every display frame during pan/zoom. That is better than one render per raw event, but it leaves the project-size-dependent React work that phase 5 was intended to remove. Move high-frequency pan/zoom into a stable store/controller and let small viewport groups and DOM-overlay positioners subscribe directly.
• Add an executable render/publication-count check. The current 25-test suite has no viewport test, so “at most one React publication per frame” is structurally plausible from the code but not currently a scripted acceptance check.

[cloudflare-workers-and-pages]

Deploying vitrai with    Cloudflare Pages

Latest commit:	138e0a3
Status:	✅  Deploy successful!
Preview URL:	https://741f1548.vitrai.pages.dev
Branch Preview URL:	https://codex-interaction-viewport.vitrai.pages.dev

View logs

[dompm]

The store correctly coalesces publication and prevents the ResultPanel/SheetPanel function itself from rerunning. The subscriber is still much broader than the requested architecture:

• [P1] Subscribe only the viewport transform and positioned overlays. The single ViewportSubscriber currently wraps the complete Stage, every layer, every pieces.map(...), Pen/Pencil overlays, crop/measure UI, and DOM properties UI. Each pan publication therefore recreates and reconciles the full canvas element tree; with hundreds of pieces this retains the project-size-dependent per-frame React work the viewport phase was meant to remove. Use focused subscriber components around each Konva viewport Group and small DOM positioners, with stable children created by the owning panel.
• The current count test proves that a synthetic parent function is not called, but its subscriber child is only a <span>. Add a regression check with an expensive/stable canvas child (or instrumentation around the real panel subtree) proving pan updates do not recreate/reconcile piece elements.

The browser smoke test confirms pan and overlays remain visually synchronized; this is a performance-architecture blocker, not a visible coordinate regression.