chore(komodo): park-lab stack for the printer bench; wiki: cover-open bug bench result

park-lab re-added to resources.toml for the reproduction box: copied from park-2 then
corrected — the copy carried park-2's review outbox (collector URL, booth-2 id, booth-2's
token), which would have fed the training pool under a booth's identity; removed, the
outbox is off on the bench. Pinned to the booth's stage-2d9bb15, comments say what the
lab is for.

Wiki, printer-usb-transport: the failing printer identified (USB 1fc9:2016 "POS-80", NXP
controller, no brand in the descriptor); attached to WSL via usbipd and cover-cycled — no
disconnect, no re-enumeration, so the stale /dev/usb bind-mount hypothesis is falsified
for this unit; the next discriminator is the monitor's offline detail text on park-buzi
(EBUSY / open timeout / EIO). WSL caveat: Microsoft's kernel lacks CONFIG_USB_PRINTER.
fleet-deployment-komodo: park-lab row updated. Log: both entries of the day.

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

wiki/concepts/printer-usb-transport.md

@@ -174,7 +174,22 @@ itself is redone.
   target on a policy-driven restart, the container can come back up still bound to the pre-incident
   view. This matches the exact reported asymmetry (reboot doesn't fix it; explicit restart does).
 
-**Not yet confirmed on hardware** — this is the leading theory, not a verified root cause. To
+> **Bench result 2026-09-09 — the re-enumeration hypothesis is FALSIFIED for this unit.** The
+> failing printer (`1fc9:2016` "POS-80", now on the dev bench, attached to WSL via usbipd) was
+> cover-cycled while `dmesg -w` and `lsusb` were watched: **nothing** — no disconnect, no
+> re-enumeration, same bus/device number (a real drop would have shown as a vhci detach, since
+> Windows sees the bus first). So the device node does NOT change when the cover opens, and the
+> container `/dev/usb` bind-mount cannot be going stale for that reason. The failure is in how
+> `usblp` / the app's open-probe reacts to the printer's **error state** (cover-open status),
+> not in the device node. Next discriminator is the **exact `detail` text** the monitor logged
+> on park-buzi at the offline transition (`docker logs <stack>-server-1 | grep
+> 'device-monitor:.*-> offline'`): `EBUSY` = a handle is held inside the server process (usblp
+> allows ONE opener — candidate: the `withTimeout` open-leak or a close that never returned;
+> fits "docker restart fixes"), `usb open timeout` = `open()` itself blocks in the kernel, `EIO`
+> = `usblp_open`'s bidirectional read submit failed (printer endpoint state). The theory below
+> is kept for the record.
+
+**Not confirmed on hardware — and now contradicted by the bench (above).** The original plan to
 confirm at the next occurrence, BEFORE restarting anything:
 ```bash
 # host:
@@ -197,8 +212,18 @@ whether the Bus/Device number changes.
    passthrough + a udev rule pinning a stable symlink name — reintroduces the renumbering fragility
    the directory bind-mount was chosen to avoid, so only worth doing alongside (1)/(2), not instead.
 
-**Open sub-question — printer identity.** The park-buzi unit shows as "Generic (unknown)" in the
-app; not yet identified by vendor/product ID. Lab reproduction uses a **RONGTA** unit instead (not
+**Printer identity — IDENTIFIED 2026-09-09.** The failing unit is on the dev bench: USB
+`1fc9:2016`, product string **"Printer POS-80"** (0x1fc9 = NXP, the printer's USB controller chip;
+"POS-80" is the generic 80 mm ESC/POS designation — no brand in the descriptor, which is why the app
+shows "Generic"). Seen via `usbipd list` on the Windows host (busid 8-1). **Dev-bench caveat:** the
+stock Microsoft WSL2 kernel (6.6.87.2) has `CONFIG_USB_PRINTER` **not set** — usbip/vhci is there,
+so the printer can be attached and seen by `lsusb`, but no `usblp` → no `/dev/usb/lpN` → the app's
+USB transport and the container's `/dev/usb` bind-mount cannot be exercised without a custom WSL
+kernel (`.wslconfig` `kernel=`) built with `CONFIG_USB_PRINTER=y`. Also, through usbip the
+cover-open disconnect is seen by *Windows* first (usbipd detaches; `--auto-attach` re-exports), so
+the bench only shows *whether* the device drops off the bus, not the host-kernel/container
+staleness itself. Previously: the park-buzi unit showed as "Generic (unknown)" in the app; not
+identified by vendor/product ID. Lab reproduction uses a **RONGTA** unit instead (not
 the same hardware), so the lab cannot currently reproduce the park-buzi symptom directly — only
 validate the general re-enumeration mechanism. Commands to identify the real park-buzi printer next
 time it's reachable via SSH: `lsusb`, `udevadm info -q property -n /dev/usb/lp1`, `udevadm info -a