Process 06.1 — WS subscribe & broadcast

Process 06.1 — WS subscribe & broadcast

Sequence for a bidder dashboard tab subscribing to a per-auction room, then receiving a batched broadcast triggered by a peer’s bid.

Key invariants illustrated:

• DO hibernates between real frames; "ping" never crosses the message handler (auto-response pair).
• Subscribe path validates session_token against KV before writing a hashed_bidder_id attachment — watchers cannot receive per-user events.
• 1-Hz alarm drives coalesced bid-pulse broadcasts. auction_closed bypasses the wait but still uses the final batch frame before closing sockets.
• Client-side last_seq in localStorage is owned by follow-up #230.
• Ring buffer of 200 per-room envelopes is the boundary between replay and resync.
• Browser pause/resume throttling and secondary events are deferred to #231.

Files (target layout):

• apps/ws/src/index.ts — Worker entry with /auction/:id forwarding the raw upgrade request to env.AUCTIONS.idFromName(id).fetch(...) so the WebSocket upgrade survives intact.
• apps/api/src/auction-do.ts — per-auction DO class (subscribe handler, batching, replay ring, terminal close-out).
• apps/ws/src/websocket-hub.ts — lobby/reveal WebSocketHub DO.
• apps/web browser-side reconnect + last_seq plumbing is tracked in #230.