Let agents discover and message channels on peer hosts

Human channel routing reaches peer hosts, but the native `channels`/`message` tools currently use the local catalog. #13 covers hosted-channel messaging; #11 and #15 cover different boundaries.

## Acceptance

- Discover reachable peer channels with stable identity and enough project/host context to select the intended destination. - Deliver attributed messages and optional agent invocations through the existing tailnet and collaborator-agent policy; expose a supported reply path. - Preserve destination-host execution, idempotent delivery, and clear offline/reconnect outcomes. - Verify with real channels/models on two hosts, including duplicate delivery/reconnect and a target whose name changes. - Keep agents in different channels as messaging peers, not parent/child owners.

This is an extension beyond #10's baseline human collaboration check. Preserve the runtime-neutral channel and injected delivery boundary.

Related: #10, #11, #13, #15. [Review evidence](https://github.com/githubnext/ace2/issues/5#issuecomment-5986485157).

Tracked by #58.

Implemented in draft #160 (branch `codex/peer-channel-messaging`, commit 14c6923). It stays a draft until the change is checked on two real hosts.

**What changed** - Workers reach their host through an owner-only, token-authenticated `host.sock` in the host's data directory. They find it by home, not port, so `ace serve --port` and desktop profiles work. It accepts only `channels` and `deliver`. Requests share the gateway's closing/updating admission and drain. - `channels` lists local channels, reachable peers' channels, and offline channels from the directory, with id, host, owner, state and project. A name shared by several channels is refused with the candidate ids. - `message` delivers to a channel this host runs, or is relayed once through a new peer-only `deliver` request. Peers never forward further. - The destination host stamps `agent.<source id>@<login>`: its own owner's login, or the peer login that `tailscale whois` verified. Caller-supplied authors are ignored, and agents are never treated as the channel owner, so sharing off still refuses agent invocation. The source id is the reply address and survives renames. - Relayed request ids are scoped to the verified login (`peer/<login>/…`) because pi dedupes per chat regardless of author. Local ids are unchanged. - With no host running (CLI-only), workers fall back to local delivery only on ENOENT/ECONNREFUSED, and say so.

**Verified locally**, with real Anthropic models on a disposable `ace serve --port 4357` profile and only disposable `ace57-*` channels: - say and invoke, plus a reply by source id after the sender was renamed; - name ambiguity, and sharing off (say allowed, invoke refused); - request id replay and peer/local id isolation, confirmed in SQLite; - token, home, `from` and request id refusals, and that a forged author is ignored; - peer `deliver` over the real self-tailnet listener, which ran real `whois` with the owner's own login; - socket lifecycle: clean stop, conflicting host, stale-socket recovery, and draining a delivery admitted at SIGTERM; - CLI-only fallback.

**Still open for acceptance** - The only online peer Mac (`nate16-1`, a different login) refuses 4140/4141/4142, so no Ace gateway is running there. - Unverified: two-host discovery and delivery, collision isolation between distinct logins, duplicate delivery and reconnect across machines, and offline peers listed by the directory. - Next step: run Ace on a second host and repeat these checks with disposable channels on both machines (#10).

Dogfooding: #5.