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

Read src/ui/dashboard-tile-gestures.ts, especially wireTileDrag and its module comment, then run the characterization cases in tests/unit/dashboard.test.ts and tests/unit/dashboard-tile-gestures.test.ts. The issue documents an existing mid-gesture engine inconsistency but leaves the desired behavior out of scope; completion requires a maintainer decision followed by an agreed implementation and updated tests.

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.