qr-reader: reply Connection: close (fixes ~10s beep delay)

The reader sends Connection: keep-alive but only acts on the verdict (beep,
output) once the TCP socket closes. Fastify's default kept the connection alive,
so the reader waited out a ~10s keep-alive timeout before beeping — even though
the server replied in ~15ms. Every vendor demo replies Connection: close and
shuts the socket. Set reply.header('connection','close') on the QR endpoint.

Verified the header is now sent; symptom was correct accept/reject with a ~10s
lag before the beep.

wiki/log.md

@@ -691,3 +691,12 @@ guarantee. Recorded in [[dingtian-relay]] (new Hardening section).
   [[dingtian-relay]] connected. NOT for production. Registered in the catalog.
 - To get a live accept: assign Stub barrier to the reader's lane + a permit whose QR = the scanned
   code → status:1 (2-beep) + logged pulseOpen.
+
+## [2026-06-16] fix | QR reader 10s beep delay — reply must Connection: close
+- Live accept worked (status:1, pulseOpen, 2 beeps) but the beep came ~10 s LATE. Server responded
+  in 14.7 ms; user confirmed request is fast, only the beep lags → delay is the READER, not us.
+- Cause: reader sends `Connection: keep-alive` but only ACTS on the verdict once the socket CLOSES;
+  Fastify kept it alive → reader waited out a ~10 s keep-alive timeout. Every vendor demo replies
+  `Connection: close` + shuts the socket.
+- Fix: endpoint sets `reply.header("connection","close")`. Verified the header is now sent.
+- Updated [[gee-qr-er80]] (⚠️ Connection: close requirement).