feat(multi-site): wire no-inbound relay registration into the real bootstrap flow

sso-manager-node/jump-host already had the relay-automation mechanism
(noInbound/meshIp/publicHost -> theta-proxy route via proxy_client.js,
GET /api/mesh/self on jump-host) but nothing in the actual operator
bring-up flow could ever reach it -- setup.sh, bootstrap/site-join.js,
and setup.env.example had zero wiring for it.

Add bootstrap/site-relay-register.js: reads this spoke's own role from
/config/site.json, logs into the local jump-host as its bootstrap
admin to discover its mesh IP, and registers it with the master. Mesh
peering itself stays a manual step (mint/paste a join token, same
pattern as the site join key), so this runs on every setup.sh
invocation via CFG_SPOKE_NO_INBOUND/CFG_SPOKE_PUBLIC_HOST and is a
no-op ("not meshed yet") until an operator has actually meshed the two
jump-hosts.

Also updates MULTI_SITE_SPEC.md's status table/TODO and the published
mesh.md docs page, which still described this as "designed but not
automated" after the API-level work had already shipped.

docs/jump-host/mesh.md

@@ -48,13 +48,17 @@ the hard ceiling this addressing scheme supports.
 - `NET_ADMIN` capability (or equivalent) on the container/host running the
   gateway, to create the WireGuard interface.
 
-## Not yet connected to directory sync
+## Connected to directory sync
 
-This mesh is a networking layer on its own. [Theta Directory's multi-site
-join](../sso/multi-site.html) (catalog + LDAP replication between a master
-and its spokes) does not currently route its traffic over this mesh — the
-two features work independently today. Routing directory sync over the mesh,
-and using the mesh to reach a spoke site with no inbound access of its own,
-are both designed but not yet automated — see the [architecture
+[Theta Directory's multi-site join](../sso/multi-site.html) (catalog + LDAP
+replication between a master and its spokes) prefers this mesh once it's up:
+a spoke that's registered a mesh IP gets its live resync pushes routed over
+the tunnel instead of the open internet, falling back to its public endpoint
+if the mesh path fails. A spoke with no public IP at all can also register as
+no-inbound (`CFG_SPOKE_NO_INBOUND` in `theta-suite`'s `setup.env`) so the
+master auto-creates a relay route through its own `theta-proxy` — the master
+terminates TLS for that spoke's hostname and relays over this mesh. The mesh
+peering itself (this page) stays a manual step on both sides; directory join
+and relay registration pick up from there. See the [architecture
 spec](https://github.com/theta42/theta-suite/blob/master/docs/MULTI_SITE_SPEC.md)
-for current status.
+for the full detail.