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.

apps/server/src/routes/qr-reader.ts

@@ -44,8 +44,14 @@ export async function qrReaderRoutes(
 
   // No auth: the reader is a machine on the isolated device subnet and offers no
   // auth on its side. Public route, like the Dingtian input push.
-  const handler = async (req: { query: ReaderQuery }) => {
+  const handler = async (req: { query: ReaderQuery }, reply: import("fastify").FastifyReply) => {
     const q = req.query;
+    // The reader sends `Connection: keep-alive` but only ACTS on our verdict (beep,
+    // drive output) once the socket CLOSES — every vendor demo replies
+    // `Connection: close` and shuts the socket. Without it the reader waits out a
+    // ~10 s keep-alive timeout before beeping. So force-close the connection.
+    // See wiki/sources/qrcode-sdk.md, entities/gee-qr-er80.md.
+    reply.header("connection", "close");
     const cardid = (q.cardid ?? "").trim();
     const mjihao = q.mjihao != null ? Number(q.mjihao) : 0;
     const serial = (q.cjihao ?? "").trim();