UHPPOTE hardware bring-up + entry-flow blocker

Brought up the real UHPPOTE controller (serial 225088491, fw 09120) end to end
and recorded a procurement-level blocker.

Verified on hardware:
- discovery (LAN scan), host-commanded openDoor on doors 1 & 2 (physically
  actuated; reason="remote open door"), and live button capture
  (reason="push button ok").

Driver/networking fixes (packages/devices/src/drivers/access-uhppote.ts):
- broadcast to subnet-directed address (lib doesn't enable SO_BROADCAST for the
  global 255.255.255.255 -> EACCES);
- Config broadcast must match the target's subnet for unicast reply routing
  (fixes the health-check timeout: 5s -> 24ms ready);
- discover across all local subnets, dedupe by serial;
- serialize all controller I/O (concurrent calls collided on UDP :60001).

Server/UX:
- load .env via node --env-file-if-exists (vars weren't being read before);
- SETUP_AUTH_BYPASS hardened: env-gated, dev + loopback only, fails closed
  otherwise; surfaced as catalog.authBypass so the wizard drops the token field;
- .env.example documents all vars; inline favicon stops a 404.
- apps/server/scripts/: uhppote-listen (live events, restores prior listener)
  and uhppote-relay (guarded door-open test).

BLOCKER (wiki/decisions/access-controller-button-flow.md): the controller's
push-button input auto-opens the relay in firmware with no report-without-open
mode, so ticket-first entry (button -> print -> open, fail-closed) is impossible
as wired. UHPPOTE can't do it on that input; ZKTeco *might* via a programmable
aux input + PULL SDK but that's unverified and needs a new driver. Entry-lane
hardware decision paused to focus on the business side.

wiki: access-controller-button-flow (blocker), zkteco-controller (stub +
assessment), uhppote-controller callout, index + log.

wiki/log.md

@@ -52,3 +52,23 @@ health badges and auto-fills serial + host on selection. Verified: catalog flags
 uhppote; discover runs and fails gracefully without hardware (broadcast EACCES);
 non-discoverable driver → 400; no token → 401. Modeled generically so cameras
 (ONVIF) can add discovery later.
+
+## [2026-06-15] test+blocker | UHPPOTE hardware bring-up + entry-flow blocker
+Brought up the real UHPPOTE (serial 225088491, fw 09120) end to end. Fixed the
+networking path: WSL2 mirrored mode, then driver bugs — subnet-directed broadcast
+(the lib doesn't enable SO_BROADCAST for global 255.255.255.255), broadcast must
+match the target's subnet for unicast reply routing (health-check timeout fix),
+multi-subnet discovery, and serialized I/O (concurrent calls collided on :60001).
+Added .env loading (Node --env-file), env-gated+fail-closed SETUP_AUTH_BYPASS, and
+an authBypass flag so the wizard drops the token field. Test scripts in
+apps/server/scripts/ (uhppote-listen, uhppote-relay).
+
+VERIFIED on hardware: discovery; host-commanded openDoor doors 1&2 (physical +
+reason="remote open door"); button presses live (reason="push button ok").
+
+BLOCKER FOUND: the controller push-button input auto-opens the relay in firmware —
+no command to report-without-opening — so ticket-first entry (button→print→open)
+is impossible as wired. UHPPOTE can't do it on that input; ZKTeco *might* via a
+programmable aux input + PULL SDK but that's unverified and needs a new driver.
+Recorded in [[access-controller-button-flow]] + [[zkteco-controller]]. Entry-lane
+hardware decision paused to focus on the business side.