Dashboard tile drag: pointerdown-time engine snapshot can disagree with live engine reads mid-gesture

In src/ui/dashboard-tile-gestures.ts's wireTileDrag, a drag gesture snapshots the active engine once, at pointerdown, into liveReflow (line 393: const liveReflow = deps.activeEngine() === 'grafana-grid';), which then governs the reflow/hit-test path for the rest of that one gesture. By contrast, deps.renderedSurface(tileId) — used for drop-target styling (setDrop, lines 449 and 451) and home-rect capture (beginMove, line 505) — is read live on every call; dashboard.ts's own implementation of that dependency re-checks its current engine each time, not just at gesture start. An engine flip mid-drag (e.g. an unrelated change-layout command dispatched while a move is active — nothing cancels an in-flight gesture on a command) makes the two disagree: the gesture keeps following whichever reflow path was active at pointerdown, while surface lookups made during the same gesture see the new engine.

Pinned by: the app-level characterization test "an engine flip mid-drag leaves the gesture on its GESTURE-START reflow path, not the live engine's" in tests/unit/dashboard.test.ts's "tile gesture concurrency characterization" block, and directly at the controller-unit level by "activeEngine() is read fresh at POINTERDOWN (not memoized at controller construction), and stays frozen for the rest of that one gesture while renderedSurface() keeps reading live" in tests/unit/dashboard-tile-gestures.test.ts.

Pre-existing latent inconsistency predating #589 (#593 refactor umbrella); wave 2's extraction preserved it verbatim (documented in the module's own doc comment, lines 17-26) rather than "fixing" it during a pure structural move. Out of scope here — filing for a deliberate follow-up decision.

Lies src/ui/dashboard-tile-gestures.ts, insbesondere wireTileDrag und seinen Modulkommentar, und führe dann die Charakterisierungsfälle in tests/unit/dashboard.test.ts und tests/unit/dashboard-tile-gestures.test.ts aus. Das Issue dokumentiert eine bestehende Inkonsistenz der Engine während einer Geste, lässt das gewünschte Verhalten jedoch außerhalb des Scopes; zum Abschluss ist eine Entscheidung der Maintainer erforderlich, gefolgt von einer abgestimmten Implementierung und aktualisierten Tests.