relay-hub: unify frame consumption so it can share a connection with manage-request handling

[Mearman]

Parent: #28

Surfaced while scoping #48's relay:use enforcement. relay-hub.ts's createRelayHub().handleConnection() owns a connection's entire frame stream wholesale via its own for-await loop, and its handleFrame explicitly drops manage-request/manage-response ("not the relay role's business"). Confirmed wire-mesh-node's server never runs a MeshSession alongside it -- a dedicated hub deployment never answers a manage-request at all today.

Enforcing relay:use (or anything else that needs to correlate a manage-request-layer grant with a transport-layer relay-connect/relay-data on the same connection) requires relay-hub.ts to become one frame handler among several dispatched by a shared consumption loop, rather than the sole owner of connection.receive(). This is the same class of problem room-client.ts's createRoomRouter already solves for room.send/room.join sharing a session's incomingManageRequests -- two independent for-await loops over one AsyncIterable would race for its items.

Scope: design and build the shared-consumption pattern for a connection that needs both relay-hub.ts's own gossip/relay-connect/relay-data handling and a MeshSession's manage-request handling at once (the "ordinary opted-in node relays for peers it's already talking to" case from the plan's own Section B reframing, not the dedicated wire-mesh-node/cloudflare-hub deployment, which can stay exactly as it is and remain open to anyone gossiped). Blocks the real enforcement half of #48.

[Mearman]

Looked at the actual relay-hub.ts source while investigating #48. Its handleFrame is already a clean, discrete per-frame dispatcher (gossip/relay-connect/relay-data), completely separate from the for-await loop in handleConnection that owns the connection's own receive() iterator. That separation is most of the way to what a shared-consumption fix needs: exporting handleFrame (plus a disconnect hook) as its own thing, with handleConnection staying as a thin convenience wrapper for a dedicated hub deployment (wire-mesh-node/cloudflare-hub keep working unchanged), would let some other consumption loop call it per-frame instead of relay-hub owning the loop outright.

That gets the plumbing in place but doesn't by itself solve relay:use. The actual open question once frames are shareable: relay-hub's own relay-connect handler would need to know whether the connection currently holds a valid relay:use grant before honoring it, and that grant only ever gets minted via an ordinary capability-request exchange over that same connection's MeshSession -- something relay-hub itself has no visibility into today, and would need some explicit channel from whatever runs the MeshSession side to relay-hub's own per-connection state. That's a real design decision (what's the shape of that channel, who owns "the current grant for this connection"), not a mechanical follow-on from the frame-sharing plumbing, which is why I didn't just build it.