Managed Codex agents receive mentions but buzz messages send fails with misleading DNS error on Desktop 0.4.26

### Summary

On macOS Buzz Desktop v0.4.26, locally managed Codex agents receive channel mentions, generate a reply, but cannot publish it. The agent reports a transient relay DNS error from `buzz messages send`, even though the agent harness is connected and online.

### Reproduction

1. In a hosted Buzz community, add a managed Codex agent (reproduced with Fizz and Honey).
2. Mention the agent in a channel thread, for example `@Fizz hi`.
3. The agent runs, reads the Buzz CLI skill, and invokes `buzz messages send --channel --reply-to --content `.
4. The command fails twice and the reply does not appear in the UI.

### Expected

The agent reply is published to the thread.

### Actual

The agent receives the mention and forms a reply, but `buzz messages send` fails with a message described by the agent as a relay DNS lookup failure. The UI shows no response because no message is delivered.

### Evidence

- Buzz ACP logs show Fizz connected to `wss://bgpv.communities.buzz.xyz`, relay observer enabled, and presence online before the mention arrived.
- The same behavior reproduced with Honey.
- macOS system DNS was changed to Cloudflare `1.1.1.1` / `1.0.0.1`; both resolve `bgpv.communities.buzz.xyz` successfully, so this is not a persistent local DNS failure.
- Existing fixes #1287 and #1363 look closely related: Codex-managed nested CLI/MCP processes need the relay hostname in the network proxy allowlist and OS sandbox network access. This release still exhibits an equivalent outbound-send failure.

### Environment

- Buzz Desktop: 0.4.26
- macOS
- Relay: `wss://bgpv.communities.buzz.xyz`
- Managed runtime: Codex ACP
- Hosted community (not a localhost relay)

### Request

Could Buzz surface the underlying `buzz messages send` error/host in the agent transcript and confirm that the managed Codex subprocess inherits the current relay hostname and sandbox network access?