Proposal: opt-in WebTransport sidecar for Kimi Web with WebSocket fallback

What feature would you like to see?

I would like to discuss an opt-in WebTransport transport for Kimi Web, initially
implemented by a CLI-supervised Windows x64 sidecar. WebSocket would remain the
default and fallback transport.

The intended boundary is deliberately narrow: WebTransport would replace only
the reliable browser byte channel. KAP would continue to own protocol framing,
authentication, subscriptions, lifecycle, and session state. In particular,
current main would remain authoritative for WS protocol v2, {seq, epoch}
cursors, subscribe_v2, transcript grades and transcript_since, and REST-based
resync. The sidecar would not create a parallel transcript or reconnect model.

The proposed behavior is:

• disabled by default behind an experimental flag;
• loopback-only, with short-lived tickets bound to the expected origin and
  browser client;
• supervised by the Kimi CLI, with bounded queues and fail-closed startup;
• WebSocket fallback when the sidecar or capability is unavailable;
• reliable streams only, with no datagrams, media, voice, or provider changes;
• no sidecar binary bundled into or downloaded automatically by the npm package.

This would provide a supported seam for transport experiments without coupling
QUIC-specific lifecycle to transcript semantics or replacing the existing
WebSocket path.

Before preparing any PR, I would like maintainer direction on three points:

1. Is an experimental native sidecar an acceptable boundary for WebTransport,
   or should Kimi Web remain WebSocket-only?
2. Should the browser adapter continue to live in this repository, considering
   the app ownership work in #1733?
3. If the direction is acceptable, is the following review sequence reasonable?
   • capability descriptor, ticket contract, and feature flag;
   • CLI-supervised sidecar and bounded KAP bridge;
   • browser adapter plus WebSocket fallback, rebuilt on top of #2094;
   • deterministic packaging and maintainer-owned signing as a separate release
     concern.

No pull request is being opened with this issue.

Additional information

A local prototype was built and tested before #2094 merged. It demonstrated the
primary WebTransport path and pre-open WebSocket fallback in a deterministic,
no-provider product fixture. The headed interaction checklist passed streaming,
focus and draft retention, scroll anchoring, selection/copy, refresh
deduplication, and layout/readability. Focused Kimi Web and transcript test suites
and type checks also passed.

That branch is not suitable for direct submission: current main has since
advanced, #2094 introduced the dedicated subscribe_v2 transcript channel, and
the prototype overlaps current transcript and WebSocket ownership. Any upstream
implementation would be reconstructed from current main and split into bounded
PRs only after maintainer alignment.

The prototype does not establish real-provider, audio/voice, cross-platform, or
production-release acceptance. Windows signing would require a separately
approved, maintainer-owned GitHub environment and workload identity; no signing
credentials or cloud resources are part of this proposal.

Start by reading current main alongside the dedicated subscribe_v2 transcript channel introduced by #2094, then review the app ownership context in #1733. This issue has no named files or tests; it is done only when maintainers approve the boundary and review sequence before implementation begins.