kap-server: WS 'abort' control frame declared in protocol but never dispatched — silently dropped (still present in 0.43.1)

Summary

The WS control protocol declares an abort control frame (schema + control-message registry), but no connection implementation under transport/ws/ dispatches it. A client that sends { "type": "abort", ... } over the control channel gets no ack, no error, no log — the frame falls into the default branch and is silently dropped.

Evidence (0.43.1, latest tag at time of writing)

• Declared: packages/kap-server/src/protocol/ws-control.ts:172-178 (abortMessageSchema, type: z.literal('abort')), registered in the control-message union at :388 and in the descriptor table at :465-469 (with abortAckMessageSchema as its ack schema).
• Never dispatched: packages/kap-server/src/transport/ws/v1/wsConnectionV1.ts:158-178 — the inbound-frame switch handles only pong / client_hello / subscribe / subscribe_v2 / unsubscribe_v2 / unsubscribe; everything else hits default: return. wsConnectionV3.ts likewise handles only subscribe. A repo-wide search finds no handler for the abort control frame anywhere under transport/ws/.
• Same shape in 0.39.0 (ws-control.ts:237-243, :548-552).

Impact

• Any client built against the declared schema can reasonably believe a WS-level abort was delivered; nothing happens server-side. The failure is invisible — no negative ack, no close, no log line.
• It compounds with a nearby gap: REST abort of an already-completed prompt returns 40402 and emits zero events, so a client using either path can strand its UI state (we hit this in the wild as part of the restart+resume hang described in our comment on #3464).

Suggestions

1. Dispatch the frame (route to prompt abort and reply with abortAck), or
2. Ack unsupported/unknown control frames with an explicit error so the failure is not silent, or
3. Remove the schema/registration until an implementation lands.

Start with packages/kap-server/src/protocol/ws-control.ts to trace the abort schema, registry, and ack schema, then inspect the inbound-frame switches in transport/ws/v1/wsConnectionV1.ts and wsConnectionV3.ts. Confirm the intended handling with the existing prompt-abort path and choose one of the issue's proposed behaviors. Done means an abort frame is no longer silently dropped and produces the agreed abort action or explicit response.