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/ARCHITECTURE.md

@@ -179,26 +179,43 @@ rewrite: the seam stays visible even while the process is one.
 
 ## Display contract
 
-Three display paths, in two classes:
-
-**Class A — video out.** A screen driven directly by the Orin over SPI/DP/HDMI.
-The renderer is a local process subscribing to the bus over loopback.
-
-**Class B — data only.** The Orin sends no video, only data; the device renders
-itself.
+**Every display is data-only.** The Orin sends no video to anything. Each device
+subscribes to the bus and renders itself.
 
 | Path | Transport | Notes |
 |---|---|---|
-| Android app | WiFi, or USB (RNDIS) | Full-featured client, richest UI |
-| ESP32 + RLCD/e-ink | WiFi, or USB/BT serial | Low-rate, glanceable subset of signals |
+| `app-flutter` | USB (RNDIS), or WiFi | The display. Full client, richest UI, also the audio sink |
+| `app-esp32` + RLCD/e-ink | WiFi, or USB/BT serial | Low-rate glanceable subset. Not in current scope |
 
-Class B devices reaching the bus over IP connect to the broker directly. For
-transports without IP (BT SPP, plain USB serial), `telemetry-gw` bridges
-serial ↔ bus rather than each device inventing its own protocol.
+Displays reaching the bus over IP connect to the broker through `svc-gw`, which
+owns the boundary. For transports without IP — BT SPP, plain USB serial —
+`svc-gw` bridges serial ↔ bus rather than each device inventing its own protocol.
 
-Because both classes are bus subscribers, adding, removing or swapping a display
+Because every display is a bus subscriber, adding, removing or swapping one
 touches no acquisition code.
 
+### Video out was dropped
+
+An earlier revision had a second class: a screen driven directly by the Orin over
+SPI/DP/HDMI, rendered by a local process. It is gone, and with it `app-hud`.
+
+The reasoning, in order:
+
+- **No connector-powered display exists.** DisplayPort's `DP_PWR` supplies 3.3 V
+  at 500 mA — and VESA-compliant cables deliberately leave it unconnected at the
+  sink. HDMI's +5 V pin gives 55 mA. A panel needs 5–15 W. So a directly-driven
+  screen always needs its own power feed, which is the cable the removable display
+  unit was meant to avoid.
+- **DSI is not available.** The Orin Nano module carries DSI on SODIMM pins, but
+  the developer kit's carrier board does not break them out; DisplayPort is its
+  only display output. DSI would require a custom carrier board.
+- **It bought nothing the browser-shaped path does not.** A data-only client on
+  one USB cable is simpler, and the display unit stays swappable.
+
+Video out is what generated the enclosure, power and cabling complexity this
+project started out trying to solve. Removing it removed the problem rather than
+solving it.
+
 ## Navigation
 
 Self-hosted and offline-first, rather than a cloud maps SDK. Japan has good LTE
@@ -309,3 +326,4 @@ rewriting the document.
 | 17 | `svc-gw` combines local hub and app gateway; no client may block the hub | Accepted | 2026-09-03 |
 | 18 | Stubs publish the real topic and schema, never a fixture-specific one | Accepted | 2026-09-03 |
 | 19 | Services mock themselves behind their own input interface; no separate stub implementations exist | Accepted | 2026-09-04 |
+| 20 | Video out (Class A) dropped; every display is data-only. `app-hud` cancelled | Accepted | 2026-09-04 |