Add navigation, Orin runtime and data flow design; rework repo naming

Navigation: self-hosted MapLibre + Valhalla + PMTiles, offline-first, with
Japan specifics (left-hand traffic via valhalla_build_admins, data volume,
CJK labels). Map matching pulled forward as Phase 2 ground truth.

Orin runtime: new document covering the 8 GB shared-memory budget,
capture-first startup tiers, failure isolation, storage and the audio graph.

Data flow: direction belongs to topics inside the Orin; the display boundary
is two simplex channels rather than one duplex socket; cloud links are
outbound-initiated only; services mock themselves rather than having separate
stub implementations.

Naming: repositories are <group>-<thing> with no project prefix, so lexical
order matches semantic grouping. Indexes the five new repos.

Decisions 8-19 recorded; 14 (recording retention) left open.

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

docs/ROADMAP.md

@@ -31,7 +31,7 @@ capture decodable later.
 ## Phase 2 — Decode
 
 - [ ] Correlate captures against the event log; identify recurring frame IDs
-- [ ] Build the Z27AG DBC incrementally in `yukart-contracts`
+- [ ] Build the Z27AG DBC incrementally in `contracts`
 - [ ] `decoder` — raw frames to named signals
 - [ ] `obd-poller` — active OBD-II PIDs, single writer, rate-limited
 - [ ] `gnss` — position/speed, useful as ground truth for validating decoded speed
@@ -52,14 +52,36 @@ Order chosen by feedback speed, not ambition.
 
 - [ ] One display end-to-end first, proving the contract — Android client is the
       quickest to iterate on
-- [ ] `yukart-hud` — directly-driven screen (Class A)
-- [ ] `yukart-esp32-display` — RLCD/e-ink glanceable subset (Class B)
+- [ ] `app-hud` — directly-driven screen (Class A)
+- [ ] `app-esp32` — RLCD/e-ink glanceable subset (Class B)
 
 ## Phase 5 — Camera and inference · *separate task*
 
 Deliberately deferred. It is the reason the compute is a Jetson rather than a
 Pi, but it shares nothing with the CAN work beyond the bus.
 
+## Navigation · *parallel workstream*
+
+Not a phase — it runs alongside, and its early output feeds Phase 2. Design is
+in [ARCHITECTURE.md](ARCHITECTURE.md#navigation); code in `svc-nav` (runtime)
+and `tool-mapmint` (artifact builds).
+
+- [ ] Confirm Valhalla builds and runs on the Jetson (arm64) — do this first,
+      it is the one real integration risk
+- [ ] Build the admin database with `valhalla_build_admins` — this is what sets
+      left-hand traffic, and it must run before the tile build
+- [ ] Build Valhalla routing tiles from a Geofabrik Japan extract, starting with
+      the region actually driven rather than all 2.3 GB of it
+- [ ] Pull a Japan basemap extract from the Protomaps daily build with
+      `go-pmtiles`; static-serve it, with `localIdeographFontFamily` set for CJK
+- [ ] MapLibre page rendering the basemap from a replayed GNSS trace
+- [ ] Moving map live in the car — **blocked on gpsd in Phase 0**
+- [ ] Meili map matching over recorded sessions, as Phase 2 ground truth
+- [ ] Routing and turn-by-turn guidance onto `yukart/nav/guidance`
+
+The map-matching item is worth pulling forward: it validates decoded CAN speed
+against OSM speed limits and road geometry, which is otherwise guesswork.
+
 ## Deferred
 
 - Live off-board telemetry over LTE — hardware is present, but local logging