A11: Typing insight (productize debug trace + join feedback)

[AsafMah]

Part of #19.

Productize the always-on gesture debug trace into a real typing-insight experience. (a) Promote GestureDebugPointsDrawingPreview from a debug flag to a polished user setting; (b) join-feedback (visual/haptic) when a tap EXTENDS a swiped word vs STARTS a new one; (c) optional post-commit "what happened" glance (which fragments merged, why this word). Pairs with B6 tuning.

Acceptance: an opt-in insight overlay that explains gesture/spacing decisions in real time.

[AsafMah]

Grounding note before implementation: the setting already exists and is user-facing. `PREF_GESTURE_DEBUG_DRAW_POINTS` -> `SettingsValues.mGestureDebugDrawPoints` is a normal toggle (not a `BuildConfig.DEBUG` / `DebugFlags` gate), consumed by `MainKeyboardView` (the `GestureDebugPointsDrawingPreview` overlay, ~line 519/556), `PointerTracker` (setGestureDebugPoints, ~366), and `InputLogic` (candidate logging, ~3714). So step (a) 'promote from debug flag to a setting' is effectively done.

What remains is the productization / UX part, which is feel-driven and best done on-device:

• (b) join-feedback (visual/haptic when a tap EXTENDS a swiped word vs STARTS a new one),
• (c) a polished post-commit 'what happened' glance,
• visual refinement + a user-friendly name/description/placement (currently 'debug'-flavored).

These need design iteration with eyes on the keyboard, not a blind mechanical change (a feedback toggle without the rendering would just be a stub). Recommend tackling this interactively/on-device (the way the #43 fix was test-driven on hardware), and gating the visual choices behind the experimental tuning so they can be felt. The pref plumbing is the easy part; the experience is the work.