buzz-acp: HTTP calls to *.local relay URL fail on macOS due to mDNS resolution delay (~5s/request)

## Summary

On macOS, using a `.local` hostname as the relay URL (e.g. `ws://buzz.local`) causes every `buzz-acp` HTTP call (`POST /query`, `POST /events`) to take ~5 seconds due to macOS mDNS (Bonjour) resolution. This makes channel discovery time out and the harness exits with an error.

## Steps to reproduce

1. Add `127.0.0.1 buzz.local` to `/etc/hosts`.
2. Set the community relay URL to `ws://buzz.local` in the Desktop app.
3. Start an agent harness (e.g. Welcome Team).
4. Observe the harness log:

```
INFO buzz_acp: connected to relay at ws://buzz.local
WARN buzz_acp::relay: POST /query network error: error sending request for url (http://buzz.local/query)
WARN buzz_acp::relay: POST /query network error: error sending request for url (http://buzz.local/query)
Error: channel discovery error: HTTP error: error sending request for url (http://buzz.local/query)
```

5. Verify the underlying cause:
```bash
time curl http://buzz.local/_readiness
# real 0m5.020s ← ~5s delay per request
```

## Root cause

macOS treats `.local` as a multicast DNS (mDNS/Bonjour) domain. HTTP clients that go through the system resolver attempt an mDNS lookup first, which takes ~5s to time out before falling back to `/etc/hosts`. The WebSocket connection is unaffected (single long-lived connection), but `buzz-acp`'s short HTTP requests all incur this penalty.

## Workaround

Use a non-`.local` TLD, e.g. `buzz.test` or `buzz.internal`, in `/etc/hosts` and the relay URL:
```
127.0.0.1 buzz.test
```
Requests then complete in ~25ms.

## Suggested fix

- Document the `.local` hostname caveat for self-hosted/local relay setups on macOS.
- Optionally: warn in the Desktop UI or `buzz-acp` startup when the relay URL uses a `.local` TLD on macOS.

## Environment

- Buzz Desktop v0.5.8, macOS (arm64)
- buzz-acp from app bundle