chrome-service: fix noVNC stuck-"Connecting" (x11vnc fd-sweep under nofile=2^31)

The noVNC view hung on "Connecting" forever then timed out. Root cause: x11vnc
sweeps the entire fd table (fcntl per fd) on every client connection, and
containerd grants pods RLIMIT_NOFILE=2^31, so the RFB handshake never completes
(websockify accepts the WS and dials localhost:5900, but x11vnc never sends its
banner — verified: handshake timed out at 8s, x11vnc had burned 1h41m CPU
spinning). Same bug + fix the android-emulator stack already carries.

Cap nofile before x11vnc starts, in two places:
- files/novnc/entrypoint.sh: `ulimit -n 65536` (root fix, makes the image correct)
- main.tf novnc container: `command = ["bash","-c","ulimit -n 65536; exec /entrypoint.sh"]`
  so the cap applies deterministically on rollout even though the image is
  :latest/IfNotPresent (a rebuilt entrypoint isn't guaranteed to be re-pulled).

Also documents the gotcha + diagnosis in docs/architecture/chrome-service.md and
notes the black-when-idle behaviour + the autoconnect URL.

(A live x11vnc relaunch with the cap already unblocked the running pod; this
makes it survive restarts.)

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

stacks/chrome-service/files/novnc/entrypoint.sh

@@ -3,6 +3,13 @@
 # and serve the noVNC HTML5 client + websockify bridge on :6080.
 set -e
 
+# Containerd grants pods an effectively unbounded RLIMIT_NOFILE (2^31). x11vnc
+# sweeps the WHOLE fd table with fcntl on every client connection, so each VNC
+# connect hangs for ~forever and the noVNC client sits on "Connecting" until it
+# times out. Cap it before launching x11vnc. (Same fix as the android-emulator
+# stack; see docs/architecture/chrome-service.md "noVNC fd-sweep".)
+ulimit -n 65536
+
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
   if echo > /dev/tcp/127.0.0.1/6099 2>/dev/null; then
     echo "Xvfb TCP up after attempt $i"