Propagate changes from main into development

[github-actions]

Automated PR to propagate changes from main into development.

Triggered by push to main.

[Copilot]

Pull request overview

This PR propagates WebSocket connection monitoring functionality from main to development. The feature adds comprehensive tracking and visibility into active WebSocket connections used for real-time log streaming.

Key Changes:

• Backend WebSocket connection tracker service with thread-safe operations
• New API endpoints for monitoring WebSocket connections and statistics
• Frontend component displaying connection status with auto-refresh
• Comprehensive troubleshooting documentation for WebSocket issues

Reviewed changes

Copilot reviewed 17 out of 18 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
backend/internal/services/websocket_tracker.go	Core service tracking WebSocket connections with thread-safe operations
backend/internal/services/websocket_tracker_test.go	Comprehensive unit tests including concurrency tests
backend/internal/api/handlers/websocket_status_handler.go	HTTP handlers for WebSocket status endpoints
backend/internal/api/handlers/websocket_status_handler_test.go	Handler unit tests
backend/internal/api/handlers/logs_ws.go	Updated to integrate WebSocket tracker with log streaming
backend/internal/api/handlers/cerberus_logs_ws.go	Updated to integrate WebSocket tracker with security log streaming
backend/internal/api/handlers/cerberus_logs_ws_test.go	Updated tests to accommodate tracker parameter
backend/internal/api/routes/routes.go	Wired up WebSocket tracker and new status endpoints
frontend/src/api/websocket.ts	TypeScript API client for WebSocket status endpoints
frontend/src/api/__tests__/websocket.test.ts	API client unit tests
frontend/src/hooks/useWebSocketStatus.ts	React Query hooks with 5-second auto-refresh
frontend/src/components/WebSocketStatusCard.tsx	UI component showing connection status and details
frontend/src/components/__tests__/WebSocketStatusCard.test.tsx	Comprehensive component tests
frontend/src/pages/SystemSettings.tsx	Integrated WebSocket status card into system settings
frontend/package-lock.json	Dependency updates and peer dependency adjustments
docs/troubleshooting/websocket.md	New comprehensive troubleshooting guide
docs/features.md	Documented WebSocket monitoring feature
docs/live-logs-guide.md	Added link to WebSocket troubleshooting

Files not reviewed (1)

• frontend/package-lock.json: Language not supported

[Copilot]

The link format on this line is inconsistent with other documentation links in the same section. Lines 595-597 and 599 use the full GitHub Pages URL format (e.g., https://wikid82.github.io/charon/...), but this line uses a relative path format (troubleshooting/websocket.md). For consistency, this should either be changed to https://wikid82.github.io/charon/troubleshooting/websocket or all links in this section should use relative paths.

[Copilot]

The documentation references an environment variable FF_IGNORE_CERT_ERRORS that doesn't appear to be implemented in the codebase. This could mislead users who follow the troubleshooting guide. Either this environment variable should be implemented to actually bypass certificate validation (not recommended for production), or this section should be removed/rewritten to focus on proper certificate configuration solutions only.

Suggested change

	#### For Self-Signed Certificates (Development Only)
	**Warning:** This compromises security. Only use in development environments.
	Set environment variable:
	```bash
	docker run -e FF_IGNORE_CERT_ERRORS=1 charon:latest
	```
	Or in docker-compose.yml:
	```yaml
	services:
	charon:
	environment:
	- FF_IGNORE_CERT_ERRORS=1
	```
	#### Better Solution: Use Valid Certificates
	1. Use Let's Encrypt (free, automated)
	2. Use a trusted CA certificate
	3. Import your self-signed cert into the browser's trust store
	#### Handling Self-Signed Certificates (Development Only)
	**Warning:** Never disable TLS certificate validation in production. Charon does **not** support an environment variable such as `FF_IGNORE_CERT_ERRORS` to bypass certificate checks.
	For development or lab environments where you use self-signed or internal CA certificates, use one of the following approaches:
	1. Terminate TLS with a reverse proxy (e.g., Caddy, Nginx, Traefik) that has a valid certificate (Let's Encrypt or a corporate CA).
	2. Issue certificates from an internal CA and import the CA root certificate into your OS/browser trust store.
	3. For a purely local self-signed certificate, explicitly add that certificate to the browser's trust store so that the WebSocket endpoint is considered trusted.
	These options keep certificate validation enabled while allowing WebSocket connections to succeed with non-public CAs.

[Copilot]

Using a token query parameter for WebSocket authentication (e.g., ?token=YOUR_TOKEN) exposes bearer tokens in URLs, which are typically logged by reverse proxies, application servers, and analytics tools. An attacker with access to HTTP access logs, monitoring systems, or intermediary infrastructure could recover these tokens and hijack authenticated WebSocket sessions or broader API access. Prefer authenticating WebSockets via HttpOnly cookies or, where possible for non-browser clients, an Authorization header and avoid placing long-lived or high-privilege tokens in URLs entirely.

Suggested change

	Charon WebSocket endpoints support three authentication methods:
	1. **HttpOnly Cookie** (automatic) — Used by default when accessing UI from browser
	2. **Query Parameter** — `?token=<your-token>`
	3. **Authorization Header** — Not supported for browser WebSocket connections
	If you're accessing WebSocket from a script or tool:
	```javascript
	const ws = new WebSocket('wss://charon.example.com/api/v1/logs/live?token=YOUR_TOKEN');
	Charon WebSocket endpoints support these authentication methods:
	1. **HttpOnly Cookie** (automatic) — Used by default when accessing the UI from a browser
	2. **Authorization Header** — Recommended for non-browser/WebSocket clients (for example, CLI tools or backend services)
	For browser-based access (the Charon UI), authentication is handled via your existing session using an HttpOnly cookie. A typical WebSocket connection from the browser would look like:
	```javascript
	const ws = new WebSocket('wss://charon.example.com/api/v1/logs/live');
	// Authentication is handled via the existing authenticated session (HttpOnly cookie); no token in the URL.