Drop video out; every display is data-only

No dedicated display is in scope, so Class A has nothing to drive and app-hud
is cancelled. Records why it will not come back: no connector-powered display
exists (DP_PWR is 3.3V/500mA and deliberately unconnected at the sink, HDMI
gives 55mA, a panel needs 5-15W), the dev kit exposes no DSI, and a data-only
client on one USB cable is simpler anyway.

Video out generated the enclosure, power and cabling complexity this project
set out to solve. Removing it removed the problem.

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

docs/ROADMAP.md

@@ -55,10 +55,12 @@ provides a cross-check for reverse-engineered ones.
 
 Order chosen by feedback speed, not ambition.
 
-- [ ] One display end-to-end first, proving the contract — Android client is the
-      quickest to iterate on
-- [ ] `app-hud` — directly-driven screen (Class A)
-- [ ] `app-esp32` — RLCD/e-ink glanceable subset (Class B)
+- [ ] One display end-to-end first, proving the contract — `app-flutter` is the
+      quickest to iterate on, and is the only display in current scope
+- [ ] `app-esp32` — RLCD/e-ink glanceable subset. Deferred, no hardware in scope
+
+Video out was dropped along with `app-hud`; see the display contract in
+[ARCHITECTURE.md](ARCHITECTURE.md#display-contract).
 
 ## Phase 5 — Camera and inference · *separate task*