Device-agnostic driver registry + first-run setup

Make the device-adapter pattern selectable so the admin chooses hardware at
install — per lane, from a catalog of supported drivers. Adding a device =
registering one more driver; no business-logic change.

packages/devices:
- interfaces.ts: AccessControlDevice / ReaderDevice / CameraDevice / PrinterDevice
  (adds CameraDevice for entry/exit snapshot-on-event; access relay stays
  intent-only per "a barrier is not a door").
- registry.ts: driver catalog with per-driver config fields + factory, config
  validation, and a catalog payload for the setup UI.
- drivers/: stub adapters — access (zkteco, esp32-relay), reader (wiegand,
  tcp-ip), camera (hikvision, dahua). Real vendor protocols TBD.

packages/db:
- lane_devices + setup_state tables (migration 0001); re-export query helpers.

apps/server:
- routes/setup.ts: GET /api/setup/catalog (public schema), and admin-only
  /assign, /state, /complete with registry validation before persisting.
- extract auth.ts (requireJwtSecret, requireRole, JWT type aug).

apps/web:
- SetupWizard scaffold + api client: pick a driver per category for a lane,
  render its config fields.

wiki: device-registry + first-run-setup concept pages; cross-link from
device-adapter-pattern; index + log updated.

Verified: full turbo build (5/5); catalog lists all drivers; admin assign
persists; missing-config and no-token requests are rejected.

wiki/concepts/device-registry.md

@@ -0,0 +1,43 @@
+---
+type: concept
+tags: [parking, architecture, devices, configurable]
+sources: [parking-system-architecture]
+updated: 2026-06-15
+---
+
+# Device Registry (selectable drivers)
+
+How the system goes from "device-agnostic in principle" ([[device-adapter-pattern]]) to
+"**admin picks the device at setup**" in practice. A **registry** holds a catalog of supported
+**drivers**, grouped by category; the [[first-run-setup]] UI reads it so an
+operator can choose a device per lane and fill in its connection config.
+
+> Implementation-derived (from `packages/devices`), not the source doc.
+
+## The four categories
+
+| Category | Examples (drivers) | Interface |
+| --- | --- | --- |
+| **access** | ZKTeco, ESP32 relay (also UHPPOTE) | `AccessControlDevice` — intent-only relay ([[barrier-not-a-door]]) |
+| **reader** | Wiegand-into-controller, TCP/IP reader | `ReaderDevice` — RF/optical; two paths ([[entry-exit-readers]]) |
+| **camera** | Hikvision, Dahua | `CameraDevice` — entry/exit snapshot-on-event |
+| **printer** | (ticket dispenser / booth printer) | `PrinterDevice` |
+
+## How a driver is described
+
+Each driver declares: a stable `id`, its `category`, a human `label`/`description`, the
+`transports` it uses (`tcp-ip`, `wiegand`, …), a list of **`configFields`** (host, port,
+credentials, selects — what the setup UI renders), and a `create(config)` **factory** that
+validates config and returns a live adapter. Adding hardware support = registering one more
+driver; **no business-logic change** — this is the [[device-adapter-pattern]] made selectable.
+
+## Why a registry (not hard-coded wiring)
+
+- The admin chooses between **multiple devices per category** at install time, per lane
+  (mirrors the "mixable per lane" principle — see [[trust-boundary]], [[entry-exit-readers]]).
+- Config is **validated against the driver's declared fields** before persisting.
+- Selections persist in the `lane_devices` table and drive runtime adapter construction.
+
+Cameras are modelled as **snapshot-on-event**: the host requests an image at entry/exit; it's
+stored and referenced from the signed event as an **independent record** — a fraud-control input
+to the [[append-only-event-chain]] (cf. [[lpr-camera]] as the recognition-based identity source).