feat(agent): ship a Node 12 executable for Windows Server 2008 R2

Machines that cannot install Node 22 had no way to run the agent at all, which
left them stuck on direct mode — and direct mode only works when the hub can
route to the VNC port, which it often cannot.

agent.js now resolves the two Node 22 globals it uses through fallbacks: `ws`
for the control and tunnel sockets, and http/https for the single enrolment
POST. Node 22 loads neither, since `globalThis.WebSocket || require('ws')`
short-circuits. The require and the http/https references are static so the
bundler can follow them.

A new Docker stage bundles that file with a Node 12 runtime — the last line
supporting Windows 7 and Server 2008 R2 — into one self-contained .exe, served
from /download/agent.exe and linked from the enrolment page. The route answers
503 rather than 404 in a dev checkout, where the build has not run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -119,6 +119,37 @@ node agent.js run    [--vnc-host H] [--vnc-port N]
 node agent.js status
 ```
 
+### Machines that cannot run Node 22
+
+Node 14 dropped Windows 7 and Server 2008 R2; nothing current will install there.
+`GET /download/agent.exe` serves the same `agent.js` bundled with a Node 12 runtime
+into one self-contained file — the enrolment page links it. Same commands, no
+install:
+
+```
+rcs-agent.exe enroll https://your-hub/enroll/TOKEN
+rcs-agent.exe run
+```
+
+The executable is built by the Docker `agent-exe` stage, so CI produces it and a
+dev checkout does not — the route answers 503 rather than 404 when it is missing.
+Build it locally with `pnpm build:agent-exe` (needs `pkg` on PATH).
+
+Two things this costs. Node 12 has neither global `fetch` nor global `WebSocket`,
+so `agent/agent.js` resolves both through fallbacks (`ws`, and `http`/`https` for
+the one enrolment POST) — that path is exercised by driving the packaged binary,
+not just the source. And Node 12 is long unpatched: it is the client half of a
+TLS connection to the hub and nothing else, but it is worth knowing.
+
+If the old machine has a VNC server but you would rather not put a binary on it at
+all, run the agent on any modern machine on the same LAN and point it across with
+`--vnc-host`. The agent does not have to live on the machine it serves.
+
+Running it as a Windows service (NSSM, `sc create`) puts it in session 0, where it
+cannot draw on the interactive desktop — the *ask first* consent dialog will never
+appear and the session will time out. On a machine with consent enabled, start the
+agent from Task Scheduler **at logon** instead, so it shares the console session.
+
 ---
 
 ## Access control