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.

Lee src/ui/dashboard-tile-gestures.ts, especialmente wireTileDrag y su comentario de módulo, y luego ejecuta los casos de caracterización en tests/unit/dashboard.test.ts y tests/unit/dashboard-tile-gestures.test.ts. El issue documenta una inconsistencia existente del motor durante un gesto, pero deja el comportamiento deseado fuera del alcance; para completarlo se requiere una decisión de los maintainers, seguida de una implementación acordada y tests actualizados.