feat(paint-editor): allow zoom while drawing

[saif-ellafi]

Description

Hello,

This PR is to allow navigating the paint editor while a drawing tool is active. This has been AI-assisted, but I tested myself.

Pinch, trackpad, and mouse-wheel still move the view; primary click-drag still draws. Secondary and middle mouse buttons pan, matching the main editor. An in-progress stroke is discarded if the view moves so path coordinates stay in one transform space.

Disable with PaintEditorConfigs.enableZoomWhileDrawing: false (also restores every mouse button drawing).

By default, the library behaves like it was before this PR. Flag needs to be set to true to benefit from this.

Implementation:

• Drawing already used a Listener on the canvas (that was upstream, for stylus latency). We only skip secondary/middle there when zoom-while-drawing is on.
• Right/middle pan is a Listener on the viewer (onPointerDown / Move / Up), because GestureDetector pan is tied to left-drag (panEnabled).
• Pinch, trackpad, wheel still go through the viewer’s existing GestureDetector / pointer-signal path, with scale enabled independently of pan.

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[hm21]

Thanks for this — really nice feature, and the write-up made the review easy. Merging with two small follow-up fixes pushed onto the branch:

1. Strokes were reported as zoom interactions. Keeping scaleEnabled on during a drawing tool also keeps the viewer's GestureDetector alive, so it reported every one-finger drag: each stroke fired onEditorZoomScaleStart / onEditorZoomScaleUpdate (per move event) / onEditorZoomScaleEnd and rebuilt the whole PaintEditor twice. Only gestures the viewer can actually act on are forwarded now — pan enabled, or a real multi-finger pinch — and a pinch that starts as a stroke emits the start it would otherwise have missed.

2. An auxiliary button pressed mid-stroke left a gap in the path. Pressing right/middle while already drawing arrives as a move event on the same pointer, not as a new one, so the stroke was only paused and then resumed with a straight jump once the button was released. It is discarded now, like every other navigation interrupt.

Added regression tests for both, plus the CHANGELOG entry and the version bump to 13.4.0. Thanks again!

[saif-ellafi]

Super glad you found it useful! Thank you Alex. Yes, it is a huge UX experience in my opinion. Will try again after your fixes , I did not notice those but sounds better now!