Hub-mode session: route agent-comms messaging through a wire-mesh relay hub (mesh.exadev.io)

[Mearman]

From live-testing the wss dial (#150) against production: connectToRemote's coordinator-approval protocol hangs against mesh.exadev.io by design -- the cloudflare-hub is a wire-mesh relay hub (drops manage-frames addressed to itself), not an agent-comms coordinator. The missing piece for 'two agents on different machines DM through the hub' is a hub-mode session:

1. Connect via wss (the wss dial: connectToRemote over ws/wss URLs (mesh.exadev.io) #150 dial leg).
2. acceptMeshSession over the hub connection (handshake already proven in the fake-hub test).
3. Gossip the self-advert -- the hub forwards to other connected peers and answers with a catch-up of everyone already there, so peers discover each other.
4. Route peer-directed messages through relay-connect pairings (sendManageRequest's existing targetDevice relay path already wraps frames as relay-data -- wire-mesh's own session layer does this; agent-comms' transport needs to use it rather than its coordinator introduction flow).

This sits on the migration's P5/history layer conceptually but needs no new wire-mesh primitives -- every piece (gossip forwarding + catch-up, relay-connect pairing, directed relay-data) is already shipped and production-verified by the hub's own live-check. It is an agent-comms-side integration design.

Out of scope here: DM/room semantics over the hub (they come along once the session itself exists), and any P5 history replication.

[github-actions]

🎉 This issue has been resolved in version 3.4.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• v3.4.0
• GitHub release

Your semantic-release bot 📦🚀