fix(reader): real ICMP liveness — QR reader status was a hardcoded "ready"

Two genuinely-offline QR readers showed GREEN: the adapter's healthCheck was
hardcoded to { ready, "stub" } and never probed. These are PUSH devices (scan →
GET our backend, resolve by serial) with NO TCP port, so a connect probe has
nothing to hit — the stub "solved" that by lying. False-healthy is the worst
failure for a status bar.

- Optional reader IP field (monitor-ONLY; scans still resolve by serial,
  operation unchanged).
- Unprivileged ICMP ping (drivers/icmp.ts): shells /bin/ping -c1, exit-0 = reply.
  No native dep, no CAP_NET_RAW. docker-compose.prod.yml sets
  net.ipv4.ping_group_range so it works for the non-root container user.
- healthCheck: replies → ready, no reply → offline, NO IP → degraded
  ("set IP to monitor") — never a false green.

Verified on hardware: readers (10.0.10.7/.8) answer ICMP on the device VLAN;
UI Test connection → "● ready — ping 10.0.10.7". Tests: reader.test.ts (4).

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

docker-compose.prod.yml

@@ -36,6 +36,13 @@ services:
     # No published port — only the proxy reaches the server, over the private network.
     expose:
       - "3000"
+    # Let the server ICMP-ping push-only readers (Dingtian/GEE QR) for an honest
+    # online/offline status WITHOUT CAP_NET_RAW: opening ping_group_range to all gids
+    # enables `/bin/ping` in unprivileged SOCK_DGRAM mode for the non-root runtime user.
+    # (The reader exposes no TCP port, so a connect-probe can't work — see reader.ts /
+    # wiki/entities/dingtian-qr-reader.md.)
+    sysctls:
+      - net.ipv4.ping_group_range=0 2147483647
     logging:
       driver: json-file
       options: