fix(desktop): connect managed agents to the configured relay, not the normalized loopback identity

[spkaplan]

Summary

Desktop-managed agents came up online but discovered 0 channels and sat idle whenever the workspace relay was addressed as localhost (the desktop default and the seeded local-dev community). They only worked when the community was addressed as 127.0.0.1.

Root cause. The relay is multi-tenant, keyed by the literal request Host, so localhost:3000 and 127.0.0.1:3000 are distinct communities with isolated channels/members. buzz_core::relay::normalize_relay_url intentionally folds all loopback spellings to 127.0.0.1 for the runtime identity key — its own doc says:

Connection code may retain the configured URL; this canonical form is for identity, receipts, status and deduplication.

But the spawn path reused that normalized ManagedAgentRuntimeKey::relay_url as the child's actual BUZZ_RELAY_URL. So an agent for a community joined on localhost:3000 connected to the empty 127.0.0.1:3000 tenant: subscribe resolved 0 channels and the agent never woke.

Fix

Connect via the configured relay URL at every spawn site, keeping the normalized ManagedAgentRuntimeKey solely as the dedup identity (receipts, pid files, logs). Four sites in desktop/src-tauri/src/managed_agents/:

• runtime.rs spawn_agent_child: use the raw relay_url param for BUZZ_RELAY_URL (not runtime_key.relay_url).
• runtime.rs start_managed_agent_process: pass the configured relay_url, not key.relay_url.
• runtime_commands.rs start_pair: same.
• runtime_commands.rs reconcile start loop: pass the raw requested community URL, not key.relay_url.

This honors normalize_relay_url's documented contract and restores channel discovery for loopback-addressed local communities. No change to identity/dedup/receipts, which still use the normalized form.

Validation

Reproduced and verified end-to-end on a local self-hosted stack (relay on localhost:3000):

• Before: agent log relay=ws://127.0.0.1:3000 -> "discovered 0 channel(s)" -> "no channel subscriptions resolved -- agent will sit idle".
• After: same agent relay=ws://localhost:3000 -> "discovered 1 channel(s)" -> "subscribed to channel <spike>", and two managed agents (a Codex harness and a cursor-agent harness) each replied to an owner @mention in-channel.
• branch-skew and desktop-tauri-checks (clippy + Tauri crate tests) pass locally against current main.

Test plan

• Create a Desktop-managed agent in a community addressed as localhost:<port>, attach it to a channel, @mention it as owner — it should discover the channel and reply.
• Confirm receipts / pid files / logs still key on the normalized (127.0.0.1) identity (no dedup regression across loopback spellings).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c071752d1c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep restart hashes on a consistent relay URL

For relay URLs whose configured form differs from the normalized runtime key (the fixed localhost case, [::1], default ports, etc.), this raw assignment also changes the value stamped into process.spawn_config_hash; later build_managed_agent_summary recomputes the hash with key.relay_url (the normalized value), so a freshly started agent is reported as needs_restart immediately even though no config changed. Split the connection URL from the hash input, or make the summary recompute with the same configured URL.

Useful? React with 👍 / 👎.