Shared compute never starts — buzz-mesh reports "relay unreachable" while the relay is reachable and buzz-desktop is connected to it

TITLE (paste into the title field, not the body):

Shared compute never starts — buzz-mesh reports "relay unreachable" while the relay is reachable and buzz-desktop is connected to it

Describe the bug

"Share this machine" never leaves "Starting…". buzz-mesh fails to reach the relay at startup, which cascades into "no live member is serving this model" and an endless mesh-runtime restart loop, so agents can never be invoked.

The relay is reachable from the same machine at the same moment — second-opinion.communities.buzz.xyz answers a websocket upgrade with HTTP 101 — and buzz-desktop holds an established TLS connection to that same host (104.18.16.37:443) while buzz-mesh reports it unreachable.

None of this is surfaced in the UI. The toggle only ever says "Starting…", so it reads as a slow load rather than a connection failure.

Steps to reproduce
Create a community and an agent
Settings → Compute → pick a suggested model → toggle "Share this machine"
Model downloads and resolves successfully
Toggle stays on "Starting…" indefinitely

@ the agent in a channel → "Could not start agent mention: Buzz shared compute cannot start because no live member is serving this model."

Reproduced with gemma-4-E4B-it Q4_K_M (4.6 GB) and Qwen2.5-32B-Instruct Q4_K_M (20 GB), after full app restarts.

Expected behavior
Sharing starts and the local model becomes available to my agents. Failing that, the UI should show the actual reason — "relay unreachable" — rather than staying on "Starting…".

Version and platform
Buzz version: 0.5.3 (Settings → Updates reports "You're on the latest version")
OS: macOS 26, Apple M5 Pro, 40 GB
Logs / additional context

Launched directly to capture stdout: /Applications/Buzz.app/Contents/MacOS/buzz-desktop

buzz-mesh: installed tokio runtime with 8 MiB worker stacks
buzz-desktop: media proxy listening on 127.0.0.1:63401
buzz-mesh: status report after startup failed: relay unreachable: could not connect to relay
buzz-mesh: ingress re-arm watchdog: [buzz-mesh-rearm] Buzz shared compute offline —
failed to re-arm local ingress for this agent: Buzz shared compute cannot
start because no live member is serving this model.
ℹ Using repackaged model from catalog: gemma-4-E4B-it-Q4_K_M
buzz-mesh: status report after heartbeat timed out
buzz-mesh: started node failed inference readiness and cleanup was incomplete:
timed out after 12s waiting for embedded mesh runtime to stop
buzz-desktop: timed out stopping Mesh runtime: timed out waiting on channel

That block then repeats indefinitely — four full cycles captured.

Relay reachability from the same machine, same network, while the app reported it unreachable:

second-opinion.communities.buzz.xyz → websocket upgrade HTTP 101
relay.damus.io → HTTP 503
relay.nostr.band → no connection
nostr.land → HTTP 101
nostr.wine → HTTP 101

If there is relay fallback logic, it may be stopping at a dead entry rather than advancing to a live one.

Ruled out by measurement:
Memory — buzz-desktop reached 47.7% of RAM with the model loaded, so loading succeeds
Model size and quantization — same behaviour on 4.6 GB and 20 GB, both Q4_K_M
Model resolution — "Using repackaged model from catalog" succeeds every cycle

Agent harness — switching Buzz Agent → Codex changes nothing; "failed to re-arm local ingress for this agent" is identical, so invocation goes through the mesh ingress regardless of harness
Network — the community relay answers on demand from this machine
Two smaller UI observations from the same session:

The download indicator read "0.0 GB / 0%" while 18 GB was actively landing in ~/Library/Caches/huggingface.

The layer-package progress repeatedly climbed to a few hundred MB and reset to 67 MB. That reset lines up with the mesh-runtime restart in the loop above.

Reproduce from Settings → Compute with “Share this machine” enabled, launching /Applications/Buzz.app/Contents/MacOS/buzz-desktop and watching the buzz-mesh and mesh-runtime logs. Trace relay connection and fallback behavior around the reported “relay unreachable” status and restart loop. Done means shared compute starts when a relay is reachable, or the UI reports the connection failure instead of remaining on “Starting…”.

Written by the indexing model from the issue text.