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/entities/gee-qr-er80.md

@@ -111,3 +111,12 @@ enter its serial here.
   `status:1` 2-beep when the QR matches a permit/open session.
 - `output` is replied as `0` (Access). Confirm on hardware whether the reader needs `1`/`2` (WG26/34)
   to drive its access line, vs. `0`.
+
+## ⚠️ Reply MUST set `Connection: close` (verified on hardware)
+
+The reader sends `Connection: keep-alive` but **only acts on the verdict (beep/output) once the TCP
+socket CLOSES**. Fastify's default keeps the connection alive → the reader waits out a **~10 s
+keep-alive timeout before beeping**, even though the server replied in ~15 ms. Every vendor demo
+replies **`Connection: close`** and shuts the socket. Fix: the endpoint sets
+`reply.header("connection","close")`. Symptom if regressed: correct accept/reject but a ~10 s lag
+before the beep. (The request arrives fast; the delay is entirely the reader waiting for close.)