chore(shot): DEFERRED — mumble-web client never paints for anonymous visitors (upstream question; loader frame is the honest web-surface view; voice fully tested via protocol tests)

machine-docs/DEFERRED.md

@@ -347,3 +347,16 @@ before the build is called done) — but does **not** force closure.
   Evidence: `grep -r MODULE_NOT_FOUND /var/lib/cc-ci-runs/{m2r,m2rr,ab}-bluesky-pds*/abra/logs/
   default/`; REVIEW-rcust.md 2026-06-11 entries. Follow-up (post-phase): file/propose a re-pin PR
   against the bluesky-pds recipe mirror.
+- mumble-web client never paints UI for an anonymous browser (phase-shot, 2026-06-11). The recipe's
+  pinned web client (rankenstein/mumble-web:0.5 via compose.mumbleweb.yml, served by websockify)
+  stays at its `loading-container` spinner ≥90s with NO console errors, NO failed asset/requests,
+  connect-dialog DOM elements absent, and no autoconnect overrides in config.local.js (defaults
+  untouched) — so the CI screenshot's best-available frame is the genuine loader view every visitor
+  gets. The voice server itself is fully exercised (protocol handshake/config tests pass; that is
+  mumble's actual function). A harness-side fix is impossible without changing what the recipe
+  deploys (guardrail: prefer upstream over cc-ci overlays). **Operator input needed:** whether to
+  pursue an upstream recipe issue/PR (newer mumble-web image or one that renders its connect dialog)
+  — until then the dashboard shows the loader frame as the recipe's web-surface reality.
+  Evidence: /tmp/mumble-probe{2,3,4}.out + /tmp/mumble-orch{4,5}.log on cc-ci (90s DOM/console/
+  network observation; websockify reachable, /ws & /websocket 404 from websockify itself);
+  /var/lib/cc-ci-runs/shot-proof-mumble/screenshot.png (L4 run, loader frame).