docs(wiki): merchant validations settled + as-built; scan input decided (camera paths postponed)

validation-discounts: driving cases → the settled validation-only model (all
money/paper at the booth) → setup UX/storage/RBAC → full as-built record.
DECIDED: merchant stations scan with a USB/HID barcode scanner on the
web/desktop app (hand-keying + Luhn as fallback); POSTPONED with analysis:
web getUserMedia scanning (secure-context TLS prerequisite on the LAN +
Code128-via-camera weakness → QR-on-ticket first) and a Tauri v2 Android
merchant app (native ML Kit scanning; Android build/sideload overhead +
configurable-server-URL prerequisite). Also: wsl-dev-networking gains the
mirrored-mode gotcha where a Windows-side listener makes a port EADDRINUSE
inside WSL while invisible to ss — Vite auto-increments and tauri dev's fixed
devUrl waits on the wrong port.

Claude-Session: https://claude.ai/code/session_01YYkpEsLmoQPaize5ec3oUm

wiki/concepts/wsl-dev-networking.md

@@ -55,6 +55,17 @@ Mirrored networking is necessary but **not sufficient** — these still bit us:
 - **`localhost` → IPv6 first.** `localhost` resolves to `::1`, but the backend binds IPv4
   (`127.0.0.1`). Node's Vite proxy can stall on the v6 attempt before falling back — point the
   proxy at `127.0.0.1` explicitly. (See [[local-dev-workflow]].)
+- **Windows-side listeners collide with WSL binds — INVISIBLY (2026-07-13).** Under mirrored
+  mode, a process listening on the WINDOWS side makes the same port `EADDRINUSE` inside WSL,
+  but it never appears in Linux `ss`/`lsof` — the port looks free yet won't bind. Bit us as
+  "tauri dev: Could not connect to http://localhost:5173 after 180s": a DIFFERENT React app's
+  dev server running on the Windows side held `::1:5173`, so the WSL Vite silently
+  auto-incremented to 5174 while Tauri's `devUrl` is the FIXED string `http://localhost:5173`
+  in `tauri.conf.json` (it cannot follow the auto-increment). Diagnose from WSL with
+  `powershell.exe -NoProfile -Command "Get-NetTCPConnection -LocalPort 5173 -State Listen"`
+  (then `Get-Process -Id <OwningProcess>`); kill with `taskkill.exe /PID <pid> /F`. Guard:
+  `strictPort: true` in the web `vite.config` so the mismatch fails in a second with a clear
+  error instead of a 3-minute hang on the wrong port.
 
 ## Multi-subnet source-address trap (the "ARP works but ping/TCP dies" bug)