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/entities/zkteco-controller.md

@@ -1,20 +1,24 @@
 ---
 type: entity
-tags: [parking, hardware, access-control]
+tags: [parking, hardware, access-control, rejected, historical]
 sources: [parking-system-architecture]
 updated: 2026-06-15
 ---
 
-# ZKTeco Controller
+# ZKTeco Controller (rejected — historical)
 
-A network access controller (C3 / inBio families) — the documented "UHPPOTE now → ZKTeco later"
-upgrade in the [[bom]]. A `zkteco` driver **stub** exists in the [[device-registry]] but the
-**real protocol is not implemented** (see below).
+> **❌ NOT USED.** Was considered as the access controller; the **[[dingtian-relay]]** board was
+> chosen instead (decoupled inputs, already verified). The `zkteco` driver **stub** has been
+> **removed** from the codebase. Kept for the record of the comparison below.
 
-## Relevance to the entry-flow blocker
+A network access controller (C3 / inBio families), originally the documented "UHPPOTE now →
+ZKTeco later" upgrade in the [[bom]].
+
+## Why it was a contender (vs. UHPPOTE)
 
 ZKTeco is **better positioned** than the [[uhppote-controller]] for host-in-the-loop entry (the
-[[access-controller-button-flow]] blocker), but this is **unverified on our hardware**:
+[[access-controller-button-flow]] blocker) — but it was **never verified on our hardware**, and the
+Dingtian solved the problem first with less effort:
 
 - Its **auxiliary inputs** have **programmable linkage** (ZKBioSecurity software / PULL SDK) and
   are **not** hardwired to "open door" — so a button on an *aux* input can raise a host event