id(connectivity): await_home_relay and check_qad_order have no production caller — serve binds, writes its lock and prints ready with no home-relay wait, and the QAD relay-order refusal can never fire #3028

Problem

pkgs/id/src/connectivity.rs defines two startup safeguards for wider-network endpoints, each with its own tests, and neither has a production caller anywhere in the repo (verified this run, below):

1. The home-relay startup wait is never awaited. HOME_RELAY_DEADLINE (connectivity.rs:92, "How long startup waits for the home relay before carrying on without one") and await_home_relay (connectivity.rs:96-105, "Waits until the endpoint has a connected home relay, for at most limit") exist so startup does not announce a server before it is reachable through its home relay. cmd_serve (commands/serve.rs:776-806) builds the endpoint with public_builder, binds it, and never calls await_home_relay; it goes on to write the serve lock file and print node: <id> status (serve.rs:~1158-1168) immediately after bind. A server can therefore present itself as ready — lock file written, node ID printed, callers detecting it via stdout — while its home relay is not yet connected (or never connects, e.g. a dead relay entry), and nothing ever reports that: the 10-second bounded wait that was built and tested for exactly this is dead code.

2. The QAD relay-order check never runs. check_qad_order (connectivity.rs:117-139) refuses a relay map with no QAD-capable relay among the first 5 entries iroh probes, because such a map "gives no public address a direct path needs". No production code calls it, and no production path constructs a custom RelayMap for it to check (public_builder, connectivity.rs:44-50, offers only the N0 preset or relays disabled), so the refusal the doc describes can never fire: the safeguard is a tested function guarding a door nothing walks through.

Evidence (this run, main ab55f3c)

• Whole-repo search for await_home_relay, check_qad_order, and HOME_RELAY_DEADLINE over all *.rs: every hit is inside connectivity.rs itself (definitions at :92/:99/:121 and the unit tests at :~290-360). Independent second grep over pkgs/id/src for production callers outside connectivity.rs returned no callers; cmd_serve's endpoint construction (commands/serve.rs:776-806) contains no relay wait and no QAD check, and a search for .online() / home_relay outside connectivity.rs found no substitute wait.
• The functions are not dead in the compiler's eyes (they are pub in pub mod connectivity, lib.rs:164), so no dead-code warning ever surfaces the gap; only a call-graph check finds it.
• Contrast inside the same file: connect and public_builder ARE wired (commands/get.rs, list.rs, put.rs, find.rs, serve.rs all call them), so the module's policy is only half applied — dials get the deadline policy, startup gets neither of its two safeguards.

Why it matters

• Startup readiness is a contract other tooling relies on (the serve lock file comment at serve.rs:~1158 says integration callers detect the server via its stdout/lock). Announcing readiness before relay reachability means early dials by node ID alone can fail or hang until their own 45s DIAL_TIMEOUT, with no log line naming the relay as the cause.
• The QAD check's doc states a real failure mode (a relay map whose first five probed entries lack QUIC address discovery yields no public address). Leaving the check unwired means the day a custom relay map IS introduced (config, tests, a deployment flag), it lands without the guard its author built for it — silently.
• This is the same unwired-policy shape as pull_policy.rs's module doc ("id serve does not read it yet", tracked in id phase-8/platform-completion: freshness-window and pull-policy config are not wired into server/world settings or CLI defaults #798 for pull policy specifically); connectivity's two safeguards have no tracking issue at all.

Acceptance criteria

• Triage confirms on current main: await_home_relay and check_qad_order have no production callers (repo-wide call search), and cmd_serve binds + writes the lock file + prints status with no home-relay wait.
• A decision is recorded on this issue: wire them, or remove/deprecate them. Wiring looks like: cmd_serve awaits the home relay under HOME_RELAY_DEADLINE when relays are enabled (skipping the wait — with a status/log line — when --no-relay is set, per await_home_relay's own doc), carrying on after the deadline as the doc promises, and logs the outcome; check_qad_order is applied to any relay map a production path actually constructs, or the function is explicitly scoped as a guard for a named future caller.
• If wired: a test or startup log line demonstrates the bounded wait (relay disabled → no wait; dead relay → startup proceeds after the deadline with a warning naming the relay wait).
• If removed instead: the constants, functions, and their tests are deleted together and the module doc no longer describes startup policy that does not run.
• No change to connect / public_builder behaviour or to the DIAL_TIMEOUT policy.

Distinct from: #798 (pull-policy / freshness config unwired in serve — different policy, different module), #795 (real-network QAD/holepunch tests owner-blocked — this issue is about the in-process check/wait never being called, not about network test access), #3023 (meta_client response deadlines).