fix(cli): supervise and deliver resolve the registered mesh instead of defaulting to loopback

[davidfarah2003]

Fixes #756.

cotal supervise and cotal deliver ignored the mesh registry and dialed nats://127.0.0.1:4222 when --server was absent, so a hand-registered mesh on a non-default broker failed with a misleading "Can't reach NATS ... Run: cotal up" while the registered broker was live.

• supervise now resolves and preflights the registered mesh via the workspace registry, carries the resolved root into Manager, and records its pid under that root.
• deliver without --server resolves/preflights the registered mesh and uses its root for daemon creds and the scan target. An explicit --server keeps the prior standalone override; injected secret-store hosting stays separate from workstation registry resolution.
• No loopback fallback: an unreachable resolved broker fails loud naming the recorded URL.
• Command help and docs/cli.md updated in the same change.

Verification: reproduced live before the fix (hand-registered mesh on a random port; supervise rc=1 dialing loopback), green after on the same shape. New CI-gated smoke:recovery-registry:live runs a live non-default JetStream broker, a hand-registered mesh, and the real CLI entry points, with explicit no-loopback checks and offline recorded-URL refusal checks. Two mutation proofs kill on the named assertions (supervise dials the registered broker; offline delivery refuses naming its recorded URL). typecheck/build/changeset all clean; delivery renewal, store-boundary, and server-resolution live smokes pass.

[davidfarah2003]

Closing as superseded: the supervise side landed via #849 (0def128 — supervise resolves the registered mesh target and explains remote host authority), and the deliver side is actively being repaired in #847 (delivery launched with the mesh's transport). The approach here (resolveTargetOrExit/preflightOrExit) conflicts structurally with the landed superviseTarget flow.