feat(zoom): add fScrollPan and fPinchStep inputs to FZoomDirective

[yaroslavyushchenko]

Summary

• fScrollPan: boolean — when enabled, two-finger scroll on a trackpad pans the canvas instead of zooming. Opt-in, default false.
• fPinchStep: number — separate zoom step for pinch gestures. When 0, falls back to fZoomStep. Default 0.

Related Issue

Closes #312

Problem

On MacBook and other precision trackpads, two-finger scroll triggers zoom instead of panning the canvas. There was also no way to tune pinch-to-zoom speed independently from mouse wheel zoom — both shared fZoomStep, but pinch gestures have very different sensitivity.

Scope

• libs/f-flow/src/f-zoom/f-zoom.directive.ts — two new inputs, wheel routing logic
• libs/f-flow/src/f-zoom/wheel-zoom.utils.ts — new isTrackpadScrollEvent utility
• libs/f-flow/src/f-zoom/wheel-zoom.utils.spec.ts — unit tests
• libs/f-examples/extensions/zoom/ — checkbox added to the live example
• apps/f-flow-portal/public/ — docs updated

Public API Impact

Two new opt-in inputs on FZoomDirective. No breaking changes. Default behavior is unchanged.

Input	Type	Default
fScrollPan	boolean	false
fPinchStep	number	0

Documentation and Examples

• f-zoom-directive.md — new inputs documented
• llms-full.txt and llms.txt — updated
• Zoom example — "Two-finger pan" checkbox added

Testing

All 140 existing tests pass. New unit test added for isTrackpadScrollEvent covering pixel-mode detection and modifier key exclusions.

[siarheihuzarevich]

Merged - thank you for this one 🙌

Quick heads-up so the follow-up doesn't surprise you: while this PR was sitting in the queue, the v19 branch (#314) grew a control-scheme feature that ended up covering the same ground - scrollPan became part of the gesture mapping (provideFFlow(withControlScheme(...)), with a Miro-like preset), and fPinchStep landed there in exactly the shape you proposed, same default and fallback.

So in the v19 merge your implementation gets unified into the scheme-driven one - the behavior survives, the code path changes:

• scroll-pan routes through the mediator (ScrollCanvasRequest) instead of setting the canvas position directly
• pan deltas are deltaMode-normalized, so line-mode wheels (Firefox mice) pan at a usable speed instead of ~3px per tick
• isTrackpadScrollEvent goes away - Chrome reports plain mouse wheels as pixel-mode too, so trackpad detection by deltaMode only holds on Firefox; the scheme semantics ("wheel pans, Ctrl/Cmd+wheel or pinch zooms") are deterministic across browsers

You're credited in the v19 changelog for proposing both features. If the per-instance [fScrollPan] input still feels needed on top of the scheme (e.g. toggling one canvas from a template), open an issue - after v19 it would be a ~15 line PR that fits the "input overrides scheme" precedence rule.

Appreciate the tests and the clean scope of this PR - if you feel like picking up something else in v19, PRs are always welcome.