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