Add KV Connect protocol v4: multiplexed watch channel over WebSocket

[piscisaureus]

Adds KV Connect protocol version 4: a multiplexed watch channel.

Today every watch() call opens its own long-lived streaming request,
so a client watching many key sets holds many concurrent streams, and
every reconnect re-delivers state the client already has. Version 4
multiplexes all watches for a database over one WebSocket connection:

• Keys are added/removed in-band (WatchChannelClientMessage), so the
  watched set changes without new connections. The add message
  carries an optional baseline (last seen versionstamp, or "absent");
  the server only sends state that differs from it. Re-adding all keys
  with their baselines after a reconnect makes resumption lossless and
  duplicate-free.
• Server messages are key-tagged and sparse (only changed keys),
  unlike the positional v3 WatchOutput.
• RemoteTransport gains optional WebSocket support via defaulted
  methods, so this is semver-compatible: existing transports keep
  compiling, keep advertising [1, 2, 3], and keep the per-watch v3
  path. Only transports that implement websocket() negotiate v4.
  Nothing changes for any current consumer until its transport opts
  in.
• The denokv server gains the /watch_channel endpoint (axum ws)
  behind the same auth, diffs updates against per-client known state,
  enforces a per-channel key cap (1024, close code 1008), and pings
  every 5s. Metadata negotiation now prefers v4.
• The watch() stream contract is identical under both protocols:
  first item is a full snapshot, later items mark untouched keys
  Unchanged, in request key order — covered by integration tests
  that exercise the channel path (shared channel across watches,
  initial snapshots, per-key updates, re-subscription) next to the
  existing v3 test.

Spec for the new endpoint and messages is in proto/kv-connect.md
("Watch Channel (version 4)").

[piscisaureus]

Pushed a revision addressing findings from a deeper review pass:

• Fallback to per-watch streaming: if the channel repeatedly cannot
  be established or keeps dying young (five consecutive failed or
  short-lived connections — e.g. an intermediary that strips the
  Upgrade header, or the server closing with a policy violation),
  subscriptions now fail with a marker error and watch() falls back
  to the version 3 streaming path instead of silently retrying
  forever. Spec updated to permit this. Covered by a new integration
  test with a transport whose websocket connections always fail.
• Subscribe/reconnect race: registering a subscription now resets
  the stored baseline of its keys (online and offline paths share one
  code path), so a reconnect that swallows the in-flight add still
  re-requests the state the new subscription needs; previously its
  initial snapshot could hang until the next write.
• Permission tightening: the channel driver only connects to
  endpoint URLs that passed the caller's check_net_url in watch();
  endpoints introduced later by metadata refreshes trigger the
  fallback (where the v3 path re-checks permissions per request)
  instead of being connected to unchecked. The check also no longer
  silently no-ops when metadata is briefly unavailable.
• v3 behavior parity: watch(vec![]) yields one empty initial
  snapshot (it used to hang on v4); watches with more than
  MAX_WATCHED_KEYS keys use the v3 path so server-side limit behavior
  is identical across versions; a malformed server frame now causes a
  lossless reconnect instead of failing every subscription on the
  channel.
• Efficiency: entries are shared via Arc during fan-out instead
  of deep-copied per subscriber; the server batches bursts of
  add/remove messages into one watcher rebuild, skips rebuilds on
  remove entirely, and validates key sizes on add; both protocol
  paths now share a single entry-conversion helper; the hand-rolled
  abort guard was replaced with tokio_util::task::AbortOnDropHandle.

One known follow-up not addressed here: the npm client throws
"Unsupported version: 4" if a user explicitly passes
supportedVersions: [1,2,3,4] against an upgraded server — the TS
client should clamp its advertised versions to those it implements.

[piscisaureus]

Review findings addressed in the latest commits:

• The channel reconnect loop now measures health by stream lifetime (30s) rather than received frames, so a server that sends a poison frame after the health window can no longer induce a zero-backoff reconnect loop; protocol errors count toward the failure limit.
• Keys larger than 2048 bytes are rejected at add time by the shared state machine instead of killing the channel.
• ClientMessageEffect::KeyAdded lets servers do a targeted read of the added key instead of a full sweep.
• Subscribing while the channel is already connected re-sends baselines correctly (no missed-update window), and an empty key set no longer hangs the driver.
• A 1008 policy close now surfaces as a channel failure that triggers the v3 fallback rather than dying silently.