Admin settings verification always fails with CSP connect-src violation, even when collaboration works (isWhiteboardPage() doesn't match /settings/admin/whiteboard)

Summary

The admin settings page at /settings/admin/whiteboard always shows "Failed to verify the connection: timeout" for the WebSocket/collaboration server, even when the server is correctly configured and real-time collaboration works fine in actual whiteboard documents.

Root cause

AddContentSecurityPolicyListener::isWhiteboardPage() only adds the configured WebSocket backend domain to the browser's CSP connect-src directive when the request path starts with one of:

/apps/files
/apps/whiteboard/recording
/s/

The admin settings page (/settings/admin/whiteboard) does not match any of these prefixes, so the CSP domain for the WebSocket backend is never added there. The admin page's own client-side verification script (whiteboard-settings.mjs) then attempts a Socket.IO connection to the configured backend URL, which the browser blocks with a CSP violation:

Content-Security-Policy: The page's settings blocked the loading of a resource (connect-src) at wss:///socket.io/?EIO=4&transport=websocket because it violates the following directive: "connect-src 'self' ..."

This surfaces to the admin as a generic "timeout" error, with no indication that it's a CSP issue rather than an actual connectivity problem.

Steps to reproduce
Configure a working WebSocket collaboration server with a valid URL and shared secret.
Confirm the server itself is reachable (e.g. via curl upgrade tests / socket.io polling handshake — both succeed).
Open /settings/admin/whiteboard.
Observe "Failed to verify the connection: timeout", even though the server is healthy.
Open browser DevTools → Console; observe a CSP connect-src violation referencing the WebSocket backend URL.
Open an actual whiteboard file under Files and confirm real-time collaboration works correctly between two clients — confirming the backend itself is fine and the failure is isolated to the settings page.
Expected behavior

The admin settings page should either:

Add /settings/admin/whiteboard (or the relevant settings route) to isWhiteboardPage() so the CSP domain is correctly injected there too, or
Surface a clearer error distinguishing "CSP blocked this check" from an actual connection timeout, so admins aren't misled into troubleshooting a non-existent connectivity problem.
Environment
Nextcloud Server: 34.0.3.2
Whiteboard app: 1.5.9
Reverse proxy: Nginx Proxy Manager (openresty)
Confirmed working: WebSocket upgrade via curl (101 Switching Protocols), Socket.IO polling handshake, JWT secret match, and live real-time collaboration across two separate browsers/users.
Additional notes

For anyone hitting this: if your WebSocket server tests out fine via curl/socket.io polling but the admin page still shows a timeout, check the browser console for a CSP connect-src violation before assuming a network/proxy issue. If collaboration actually works when editing a real whiteboard file, this cosmetic admin-page error can safely be ignored.

Start by locating AddContentSecurityPolicyListener::isWhiteboardPage() and the admin verification code in whiteboard-settings.mjs. Reproduce the check at /settings/admin/whiteboard while watching the browser console, then confirm the page's CSP permits the configured WebSocket backend and the verification no longer reports a misleading timeout.