Commit tune maps and research so tunes are reachable from the phone

Removes the *.hex/maps_cache gitignore rule (explicit user call, reversing
the earlier no-redistribution stance) so the official TuneECU catalogue
maps, derived SAI/O2-delete composites, and the checksum/composition
tooling are actually available to pull up on a phone browser when using
the real TuneECU app. Also folds in tonight's KWP2000 fixes (TesterPresent
keep-alive, connect-failure cleanup, slow-init StartCommunication fix) and
the accumulated research docs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FP2GaxS9HkUdL5sLBnjKje

tunie/docs/ROADMAP.md

@@ -74,6 +74,19 @@ Ordered by dependency. Phases 1–2 are safe reads; 3+ is the write path.
 - Cross-check the dump against our decrypt/unpack: a stock dump should reconstruct
   to the same flat ROM as the matching `.hex`, validating the whole pipeline on the
   real bike's data.
+- **Before implementing this ourselves, reverse-engineer TuneECU's own Recovery
+  mode first** (Aug 2026 finding, `../research/TUNING_IMPL_PLAN.md`): TuneECU has
+  a dedicated Recovery function (`menu_recovery` in the decompile, dispatched
+  through the same mode-switch machinery as the rest of `m.java`'s `Ue()`), with a
+  multi-year, multi-ECU-family bug-fix history in the app's own changelog (5DM/7SM,
+  Dorsoduro/Shiver 750, Walbro, Ducati recovery bugs fixed 2019-2021) — real
+  evidence this isn't a trivial retry loop, it's hardened against failure modes
+  only discoverable across many real units. Extracting and understanding that
+  procedure statically, before ever attempting our own upload/write path on the
+  one ECU we have, meaningfully de-risks this phase. **Near-term (not blocked on
+  this):** use TuneECU's own app's "Read Map" for the actual first dump — this
+  reverse-engineering is prep for when `tunie` builds its own upload path for
+  real, not a prerequisite for getting one file off the bike today.
 
 ### B3. Finish the calibration model
 - **Absolute scaling** for fuel and ignition (units), via an XDF cross-check (~€70
@@ -89,7 +102,28 @@ Ordered by dependency. Phases 1–2 are safe reads; 3+ is the write path.
   the strongest lead. `miikasyvanen/FastECU` shows a full end-to-end flow.
 - Finish **seed/key**: which of the 3 AES keys + the seed-block padding (one
   captured pair from the bike/logging APK settles it).
-- **ECU flash checksum** at write time.
+- ~~**ECU flash checksum** at write time.~~ **Solved, Aug 2026** — see
+  `../research/reference-maps/checksum.py`. 16-bit sum-of-words over the
+  flat-ROM calibration region (`0x50000`-`0x60000`, the same range this
+  project's own `table_map.py` already uses), stored in the region's last 2
+  bytes. Validated against 6 real, unmodified, official downloads —
+  computed matches stored, exact, every time. **Caveat that keeps this from
+  being "done done":** this is the *app-side* checksum TuneECU computes for
+  its own map-info display (flags "*No-OEM"/"Error" on mismatch) —
+  confirmed it's not a hard gate on its own, since a real community file
+  with a stale (unrecomputed) checksum apparently still worked for people.
+  Whether the ECU's own bootloader *also* independently verifies something
+  during the actual `0x36` TransferData sequence is a separate, still-open
+  question — this solves "how do I produce a checksum TuneECU accepts as
+  valid," not necessarily "the ECU's own integrity check."
+- **Head start already done (Aug 2026):** `../research/WRITE_PATH.md` traced
+  TuneECU's actual shared write/reprogram routine from the mode-flag entry
+  point down through the connection/retry driver into a 5-baud slow-init
+  bit-bang for the Triumph K-line address (`0xD5`) — real protocol detail,
+  not a plan. Traced as far as the post-slow-init handoff (unopened). Read
+  that before starting this section for real; it's ahead-of-time
+  reconnaissance done opportunistically while tracing Recovery mode
+  (`../research/RECOVERY_MODE.md`), not yet validated against a live ECU.
 - **Recovery**: `v-ladimir/audprog` (AUD debugger) for SH705x un-brick via the PCB
   debug pins — mandatory backstop when developing a flasher.
 - Develop against a **spare/bench ECU**, on a stable supply, never the bike's only