Remove UHPPOTE/ZKTeco; Dingtian is the only access driver

Neither UHPPOTE nor ZKTeco is used — the Dingtian relay controller was chosen
and verified. Remove their code and re-scope the wiki.

Code:
- delete access-uhppote.ts, uhppoted.d.ts, access.ts (zkteco/esp32-relay stubs),
  and the three uhppote-*.mjs hardware test scripts.
- remove the `uhppoted` npm dependency from @parking/devices and @parking/server.
- unregister uhppote/zkteco/esp32-relay from the driver registry; drop their
  exports. Catalog access drivers = dingtian only. Build green (5/5).
- refresh now-stale example comments (registry/interfaces/setup/api) to use
  current examples; keep the two "UHPPOTE blocker" references that explain why
  the precondition capability exists.

Wiki (kept pages, re-scoped):
- uhppote-controller, zkteco-controller -> rejected/historical with callouts;
  uhppote-vs-esp32 -> historical (detection-vs-prevention lens still useful).
- re-point all "current device" framing (standing-decisions, bom, overview,
  open-questions, device-registry, device-discovery, index) to dingtian-relay.
- transferable concepts (network-isolation, event-log-ingestion, barrier-not-a-
  door, threat-model) untouched. Raw source immutable. Links lint clean.

wiki/concepts/device-discovery.md

@@ -20,17 +20,23 @@ device carries an `id`, a `label`, a `config` blob to **auto-fill** the setup fo
 (firmware, MAC, …). The [[device-registry]]'s `isDiscoverable()` guard lets the system treat it
 as optional; the setup catalog returns a `discoverable` list of driver ids.
 
-## UHPPOTE discovery
+> **No current driver implements discovery.** The [[dingtian-relay]] board uses a fixed IP
+> (entered/known at setup). The capability remains for future UDP-discoverable devices (cameras
+> via ONVIF, etc.). The worked example below is the (removed) UHPPOTE driver — kept because the
+> **broadcast gotchas are transferable** to any UDP discovery we add later.
 
-The [[uhppote-controller]] supports discovery natively: a **UDP broadcast** (`get-devices` on
+## UHPPOTE discovery (historical example)
+
+The [[uhppote-controller]] supported discovery natively: a **UDP broadcast** (`get-devices` on
 port `60000`) that **every controller on the LAN answers** with its serial, IP, netmask, gateway,
-MAC, firmware version, and date. The official `uhppoted` lib exposes this as `getDevices(ctx)`;
-the `uhppote` driver maps each result into a `DiscoveredDevice` (serial → id, IP → host).
-**Verified on real hardware** (serial 225088491).
+MAC, firmware version, and date. The `uhppoted` lib exposed this as `getDevices(ctx)`; the
+(now-removed) `uhppote` driver mapped each result into a `DiscoveredDevice` (serial → id, IP →
+host). **Was verified on real hardware** (serial 225088491).
 
 ### Broadcast gotchas (learned the hard way — see [[wsl-dev-networking]])
 
-These cost real debugging time; the `uhppote` driver now handles all three:
+These cost real debugging time; the (removed) `uhppote` driver handled all three, and any future
+UDP-discovery driver will need to as well:
 
 1. **Broadcast to the *subnet-directed* address, not the global `255.255.255.255`.** The
    `uhppoted` lib only calls `setBroadcast(true)` when the target matches a **local interface's

wiki/concepts/device-registry.md

@@ -38,7 +38,8 @@ driver; **no business-logic change** — this is the [[device-adapter-pattern]]
 - Config is **validated against the driver's declared fields** before persisting.
 - Selections persist in the `lane_devices` table and drive runtime adapter construction.
 - Drivers may optionally implement **[[device-discovery]]** (`discover()`), so the admin can scan
-  the LAN instead of typing connection details — UHPPOTE does this today.
+  the LAN instead of typing connection details — no current driver uses it (the UHPPOTE did,
+  before removal; the [[dingtian-relay]] uses a fixed IP).
 
 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

wiki/concepts/uhppote-vs-esp32.md

@@ -7,6 +7,11 @@ updated: 2026-06-14
 
 # UHPPOTE vs. Custom ESP32 — Detection vs. Prevention
 
+> **Historical comparison.** Neither is the current device — the [[uhppote-controller]] was
+> **rejected** (entry-flow blocker → [[dingtian-relay]] chosen) and the [[esp32-custom-controller]]
+> is **deferred**. Kept because the **detection-vs-prevention** framing on the [[trust-boundary]]
+> fork is a durable lens that applies to any access device.
+
 A head-to-head on the [[trust-boundary]] fork: the off-the-shelf [[uhppote-controller]] versus
 the [[esp32-custom-controller]]. (Synthesized from [[parking-system-architecture]] §6–7.)
 
@@ -23,9 +28,10 @@ the [[esp32-custom-controller]]. (Synthesized from [[parking-system-architecture
 
 ## Bottom line
 
-- The UHPPOTE is the **current choice**: good enough as a detection/audit layer **when only the
-  host can reach it** (isolation) and every event lands in the [[append-only-event-chain]].
-- The ESP32 is the **documented upgrade** when you need a control path that holds even against an
-  attacker on the wire. They're **mixable per lane**.
+- The UHPPOTE was the **detection-grade** option: good enough as a detection/audit layer **when
+  only the host can reach it** (isolation) and every event lands in the [[append-only-event-chain]]
+  — but it was rejected for the entry lane (the button blocker).
+- The ESP32 is the **prevention-grade** option when you need a control path that holds even against
+  an attacker on the wire. Deferred.
 - Both still rely on host-side integrity ([[append-only-event-chain]]) and external
   [[reconciliation]] as the ultimate anti-fraud control.