minesweeper leaves the platform; plugin sockets relay ws-to-ws

Minesweeper is now plugins/minesweeper (gitea.officer.dev/plugins/minesweeper).
Removes /api/minesweeper, the Dashboard screen, the officerdev panel, the
permission registry entry, the App.tsx route and the hand-written websocket
provider in server.tsx. Registry entries: 22 -> 21, execution 4 -> 3.

The relay changed transport, and that is the part worth reading.

A sidecar announces exactly one port. That single announcement is the whole
provenance argument in target.ts — the platform watched the port arrive at
registration, which is the only thing separating it from a number a manifest
asserted. But a raw-TCP relay requires that port to BE a raw TCP listener, so
the sidecar cannot also serve HTTP on it, and the plugin's ordinary routes
have to fall back to the typed command vocabulary over the registration
socket. That is the mechanism the fleet has spent months retiring, and
Minesweeper would have been the first thing to go back to it.

Relaying websocket-to-websocket dissolves the conflict. The sidecar serves
HTTP and /ws on the one port it announced, exactly as the pty sidecar already
does; createSidecarProxy handles the HTTP half; and the conversion from frames
to whatever the plugin actually speaks happens inside the plugin, which is the
only process that knows. The relay is still ignorant of the payload — the
ignorance sits one layer up.

Also: the caller's JWT is no longer forwarded upstream. A sidecar has no use
for it and forwarding one puts a bearer token into whatever that process logs.
X-Officer-User carries the only part it needs. (The terminal relay still
forwards its token to the pty sidecar; not touched here.)

Verified: bunx tsgo clean, bun test 1403 pass / 0 fail, bun run docs:check
green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

src/server.tsx

@@ -16,7 +16,6 @@ import { resolveAuthToken } from './servers/auth-token';
 import { isWsProviderAllowed } from './servers/permissions/authorize';
 import { isTokenBlacklisted, getUserById } from 'officerdb';
 import { terminalWebsocket } from './servers/api/terminal/websocket';
-import { minesweeperWebsocket } from './servers/api/minesweeper/websocket';
 import { chatWebsocket } from './servers/api/chat/websocket';
 import { chatNotifyWebsocket } from './servers/api/chat/notify-delivery';
 import { registerChatPushNotifications } from './servers/api/chat/notify-push';
@@ -162,7 +161,6 @@ const handlers: Record<string, any> = {
   'chat-notify': chatNotifyWebsocket,
   'task-runner': taskRunnerWebsocket,
   pipeline: pipelineWebsocket,
-  minesweeper: minesweeperWebsocket,
   sidecar: sidecarWebsocket,
 };
 
@@ -189,7 +187,6 @@ const WS_ROUTES: Record<string, UpgradableProvider> = {
   '/api/tasks/run/ws': 'task-runner',
   '/api/tasks/pipeline/ws': 'pipeline',
   '/api/terminal/ws': 'terminal',
-  '/api/minesweeper/ws': 'minesweeper',
   '/api/chat/ws': 'chat',
   '/api/chat/notify/ws': 'chat-notify',
 };
@@ -368,7 +365,7 @@ console.log(
  * cannot serve is now a typecheck failure instead of a runtime one. `sidecar` and `dev-proxy` are
  * deliberately absent — they upgrade through their own handlers, not through here.
  */
-type UpgradableProvider = 'terminal' | 'chat' | 'chat-notify' | 'task-runner' | 'pipeline' | 'minesweeper';
+type UpgradableProvider = 'terminal' | 'chat' | 'chat-notify' | 'task-runner' | 'pipeline';
 
 async function upgradeWs(req: Request, server: any, provider: UpgradableProvider) {
   const token = new URL(req.url).searchParams.get('token');