[FEATURE] Admin API WebSocket management

[pr0head]

Problem

There is currently no way to inspect or control active WebSocket connections at runtime through the Admin API. Once a client connects to a WebSocket mock, the server has no management interface to:

• see which connections are currently open
• close a specific connection programmatically
• push a message from the server side to a connected client

This makes it impossible to fully test server-initiated WebSocket scenarios or clean up connections between test runs without restarting the entire mock server.

Proposed Solution

Add a WebSocket connection management group to the Admin API:

Method	Path	Description
GET	/websocket/connections	List all active connections with aggregate stats
GET	/websocket/connections/{id}	Get details for a specific connection
DELETE	/websocket/connections/{id}	Close a connection
POST	/websocket/connections/{id}/send	Send a text or binary message to a connection
GET	/websocket/stats	Get aggregate WebSocket statistics

Use Case

Scenario 1 — Server-initiated push
A test needs to verify that a frontend correctly handles an incoming WebSocket event (e.g. a price update, a notification). Today this requires setting up a real backend. With this API the test can POST /websocket/connections/{id}/send to push the event directly from the mock.

Scenario 2 — Test cleanup
An integration test suite opens WebSocket connections during each test. Between runs the suite calls DELETE /websocket/connections/{id} (or iterates GET /websocket/connections) to forcefully close any lingering connections instead of restarting the server.

Scenario 3 — Monitoring & debugging
A developer watching a long-running test can query GET /websocket/stats or GET /websocket/connections to see how many clients are connected and how many messages have been exchanged, without needing to add custom logging.

Additional Context

The SSE protocol already has equivalent endpoints (GET /sse/connections, DELETE /sse/connections/{id}, GET /sse/stats) — the WebSocket API should mirror that design for consistency.

The underlying ConnectionManager in pkg/websocket/manager.go already exposes ListConnectionInfos, GetConnectionInfo, CloseConnection, and SendToConnection — the missing piece is the Admin API surface on top of it.

[zach-snell]

Hey Vadim, thanks for the really solid work on this and #10 (plus PRs #9 and #11). We've reviewed both thoroughly and the code quality is great — clean architecture, good test coverage, follows existing patterns well.

After reviewing we realized this pattern (connection management + auto-disconnect on mock update) should be applied consistently across all connection-style protocols, not just WebSocket. Right now:

• SSE has a ConnectionManager and admin endpoints but no auto-disconnect on mock update
• MQTT has a SessionManager internally but no admin API for per-connection management
• gRPC supports streaming but has no connection tracking at all

We're planning to take your work as the foundation and build a unified PR that brings all connection protocols up to the same level. This would include the WebSocket changes from #9 and #11 plus extending the same patterns to SSE, MQTT, and gRPC.

A few things we'd want to address in that unified pass:

• Revert the Docker CI trigger change in Close the WebSocket connection when ws-mock changes. #11 (.github/workflows/docker.yaml — the branches: ["*"] change looks accidental)
• Add type field validation on the send endpoint (reject unknown values with 400)
• Align the documented response fields with what the adapter actually populates (clientIp, bytesSent, etc.)
• Remove the unused GetEmptyStats() from the stats provider interface

Also agreed on the connection close with 1012 approach over hot-update — it's cleaner, predictable, and works regardless of what changed in the mock config. ScenarioExecutor holding a reference to the old scenario makes hot-update impractical anyway.

Not closing your PRs — we may end up cherry-picking or basing off your branches directly. Will keep you posted. Really appreciate the contribution, this is exactly the kind of feature gap we needed filled.

[pr0head]

Hey Zach!

Thank you for letting me know about your plans; this will be helpful.
I've fixed all the requests you mentioned in your comment.