B7c: Adaptive connector bridge + distance-based re-timing

[AsafMah]

Part of #97. Depends on B7b.

Replace fixed 25 ms/60 ms with distance-aware timing and an adaptive prefix→suffix connector:

• small gap (< 0.6*keyWidth): normal join (~45 ms);
• medium (0.6–2*keyWidth): fast bridge, ≤1 midpoint;
• large (≥ 2*keyWidth): teleport — no intermediate points, short dt (12–25 ms), so the connector doesn't trace unrelated keys.

Re-time points by dt = clamp(distance / velocity, 8, 28 ms).

Acceptance: golden-corpus (#21) A/B — swipe→swipe and long-jump combos improve; connector-letter hallucinations (techcolony) drop; no regression elsewhere.

[AsafMah]

Measured and falsified — the re-timing half of this should not be built.

PR #136 built a host harness that runs the real AOSP ProximityInfoState and measured what actually moves points between the decoder's two pointer tracks. Result: updateTouchPoints partitions purely on pointer id. Shifting or overlapping timestamps moves zero points between tracks (asserted by test).

Worse, deliberately overlapping strokes drives the computed speed rates negative — arithmetically impossible from real input, so it feeds garbage into the closed weighting. Global time monotonicity is also still required, since refreshSpeedRates walks raw indices across the pointer boundary.

So "distance-based re-timing" to make two strokes look simultaneous is a dead end: the one temporal change it proposes is the one that measurably degrades the decoder.

What does work is the pointer-id lever — see #136 and #29. Suggest re-scoping this issue to the connector-bridge half only, or closing it in favour of #29.

Details and the measurement table: docs/TWO_THUMB_TEMPORAL_ALIGNMENT.md.