relay-hub: relay:use capability + client-side no-relay opt-out

[Mearman]

Parent: #28

Remaining scope from #30, split out because #46 (the multi-pairing fan-out fix) closed #30 by its own Fixes #30 keyword even though this part wasn't built yet.

relay:use capability

Gates who may ask an ordinary, opted-in node to relay for them -- scope kind node, token required, same rationale class as webrtc:signal/room:member: using a volunteer's bandwidth/connectivity has a real receiver-side cost. A dedicated hub deployment (wire-mesh-node/cloudflare-hub) can reasonably stay open to anyone gossiped, the way it works today; an ordinary opted-in node can require this token before accepting relay requests from strangers. Blocked by #102: enforcing this needs relay-hub.ts restructured to consume manage-request frames alongside relay frames, which it doesn't do today (it drops them outright).

Client-side no-relay opt-out -- confirmed already done, no further work needed

? direct-only: bool on relay-connect-frame was tried during #46 and reverted -- it has no coherent hub-side meaning, since relay-hub only ever receives relay-connect once the sender has already decided to relay. The real decision point is upstream: whether sendManageRequest's own targetDevice-triggered relay-routing path gets called at all.

Confirmed by reading the actual shipped code (mesh-session.ts's sendManageRequest, room-client.ts's sendRoomMessage/requestToJoin): targetDevice is optional throughout, and targetDevice !== undefined is the sole trigger for relay wrapping (ensureRelayPairing + transmit(frame, true)). A caller that omits it gets transmit(frame, false) -- always direct, never relay. room-client.ts's own doc comment already states this plainly ("omit it for a session that already is the direct connection"). This is exactly the opt-out described here, delivered as a natural consequence of #32's own API design, not a separate feature that still needs building.

This issue's own remaining scope is therefore just the relay:use capability above, blocked by #102.

Full detail: the plan file's section B, and #30's own now-superseded body.

[Mearman]

Investigated directly against the current source before implementing. Two real findings that change this issue's scope:

relay:use itself needs zero new CDDL. management.cddl already ships capability-request/capability-grant-ok (#78, merged) as the generic ungated capability request/grant primitive -- a requester sends capability.request with capability: "relay:use", scope {kind: "node"}, and gets a token back via the existing capability-grant-ok response. No new verb, no schema change, no conformance vector regen needed for the capability itself.

Enforcing it is a real architectural blocker, not a field addition. relay-connect-frame deliberately carries no token field (its own spec comment says so: gating belongs to "an ordinary core/management verb checked before honouring subsequent relay frames on that connection"). But relay-hub.ts's createRelayHub().handleConnection() owns a connection's entire frame stream wholesale via its own for await (const frame of connection.receive()) loop, and explicitly drops manage-request/response as "not the relay role's business" -- confirmed wire-mesh-node's server never runs a MeshSession alongside it, ever. Correlating a manage-request-layer grant with a transport-layer relay-connect on the same connection needs relay-hub.ts restructured from "owns the connection wholesale" to "one frame handler among several dispatched by a shared consumption loop" -- the same class of fix room-client.ts's createRoomRouter already exists to solve for a different pair of consumers, but not yet built for relay-hub.ts. This is comparable in scope to that unification work and needs its own design pass, not a quick slice bundled into this issue.

Splitting: this issue now covers only documenting relay:use as a capability convention (no code) and the already-correctly-scoped client-side no-relay opt-out (tracked separately with #32, now closed -- that part may need its own fresh issue since #32 shipped without it). Filed the relay-hub consumption-unification prerequisite as its own issue.