docs(adr): record central print service over direct printing

docs/adr/0002-central-print-service-over-direct.md

@@ -0,0 +1,17 @@
+# Central print service routing to networked label printers
+
+**Status:** accepted
+
+Cards reach board printers through a small internal print service: the CLI renders client-side, then POSTs the card image + board-id to the service, which forwards the raster to that board's networked Brother QL-1110NWB by IP. We chose this over direct CLI→printer and over corporate CUPS queues because at 50+ boards the dominant cost is operational — a board→printer registry, retries, and "did it print / is it out of labels" visibility — which a central router provides and 50 hand-configured connections do not (serves G2/F4).
+
+## Considered options
+
+- **Direct-to-printer (T-A).** No server, but 50 addresses to track, cross-floor reachability issues, and no central status.
+- **Central service (T-B, chosen).** One registry + `--board` routing + status; also the future home of the F5 short-link redirector.
+- **Corporate CUPS (T-C).** Reuses IT ops, but label media/routing is awkward in generic queues and couples the project to IT's roadmap.
+
+## Consequences
+
+- The service is a single point of failure: if it is down, printing stalls. Mitigation (watched, not built for v1): keep it simple/HA and let the CLI cache the registry to fall back to direct-print.
+- Printers must be networked (QL-1110NWB) rather than USB-only — slightly pricier per unit, but avoids a Raspberry Pi agent (and its patching burden) on every board.
+- Rendering stays client-side; the service is a thin router, not a renderer.