security(vnc): both VNC launch paths bind the RFB port on every interface although only loopback websockify uses it #17055

Problem

Both VNC server launch paths bind the VNC port on every interface, although their own websockify only ever connects over loopback.

• Compose/backend path: autobot-backend/desktop_streaming_manager.py:541 starts x11vnc -rfbport … -shared -forever without -localhost, so x11vnc listens on all interfaces. Its websockify connects to localhost:{vnc_port} (:455).
• Ansible/SLM path: roles/vnc/templates/vnc-server.service.j2:34 passes -localhost no explicitly. Its websockify (vnc-websockify.service.j2) also connects via localhost.

The raw RFB port is therefore reachable from the network, and it is protected only by the 8-byte VNC password (see #16299).

Decision needed

-localhost no in the Ansible template is an explicit choice, not an omission. It is unknown whether any workflow depends on a direct VNC client, for example an admin over VPN. History: #2409 (closed) found that a websockify loopback bind broke inter-container VNC access. That concerned websockify, not the VNC server, but it is why this needs a decision rather than a silent flip.

Recommendation: bind the VNC server to loopback on both paths, since websockify is the only consumer. If direct client access is a real use case, make it an explicit, default-off SSOT setting.

Acceptance criteria

• Decision recorded on this issue.
• Both launch paths bind the VNC server per the decision; the default is loopback-only.
• If direct access is kept, it is an SSOT setting that defaults to off, with no hardcoded bind value.
• A deploy-time or template test asserts the rendered bind flag.

Related: #16299, #2409.