fix(desktop): supervise and re-arm relay-mesh runtime

[micspiral]

Refs #2062

This carries forward the relay-mesh recovery work from #2304 by @Bartok9 (cherry-picked with original authorship/sign-offs) and adds the startup/readiness supervision and packaging fixes found while validating it against a real two-machine Buzz setup.

From #2304

• Watch the local OpenAI ingress (:9337) after launch and re-arm a stale relay-mesh runtime.
• Require consecutive failed probes before eviction so a transient inference stall does not cause a cold restart.
• Bound stale-runtime shutdown, preserve runtime identity across the asynchronous probe, and never evict a concurrent replacement.
• Re-arm only for agents that are actually running; deliberately stopped agents stay stopped.
• Persist an actionable sentinel error under the managed-agent store lock and clear only that error after recovery.
• Treat serve-to-client fallback as an intentional fail-safe; configured serve restoration remains on its existing path.

Added here

• Use the inference ingress (:9337), rather than management port :3131, as Buzz's client-readiness boundary. A usable client no longer fails or holds agent-save open merely because management startup is still pending.
• Supervise the embedded SDK startup asynchronously, publish a pending status while management is unavailable, and keep its mesh identity alive.
• Avoid racing a replacement while SDK startup still owns the embedded runtime. If that pending startup later loses ingress while a running agent still needs it, request a controlled Buzz restart to reclaim the otherwise-unreachable SDK thread.
• Defer roster-driven replacement while client management startup is pending.
• Keep post-launch recovery in a dedicated module so the mesh entry point remains within the desktop file-size gate.
• Explicitly mark generated Unix sidecars executable. On macOS, copying over an existing non-executable destination preserved its old mode, causing packaged buzz-acp, buzz-agent, and tool sidecars to be reported as missing.

Validation

Automated:

• just ci — passed, including formatting, Clippy with warnings denied, desktop/web/mobile checks and tests, and builds.
• Full Tauri mesh-feature suite — 1,702 passed, 0 failed, 15 ignored.
• Mesh-feature Clippy with -D warnings — passed.
• Release macOS app bundle with mesh-llm — built successfully; every bundled sidecar passed executable-mode and deep code-signature verification.

Live two-machine E2E:

• M5: released Buzz serving unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_M.
• Mac mini: this branch's packaged Buzz running a saved buzz-agent/relay-mesh agent.
• Confirmed :9337 accepted inference and the saved ACP harness started with no error while :3131 was still unavailable.
• Exact inference succeeded before restart (CORRECTED-MINI-E2E-OK).
• Bespoke Buzz shut down cleanly in 2.3s, then restored ingress and the saved harness in 18.8s while :3131 was still unavailable.
• Exact inference succeeded after restart (AFTER-RESTART-E2E-OK).
• A real Buzz @C55 message traversed desktop → buzz-acp → buzz-agent → mini :9337 → M5 compute and published the requested reply successfully.

[Bartok9]

Contributor note from #2304 (Bartok9)

@micspiral — thank you for taking this over after validating against a real two-machine setup. Moving here as a fellow contributor (happy for you to keep driving the code).

Credit: Clean and appreciated. PR body credits #2304; 7 commits remain authored/signed as Bartok9 (ee358742ff…1032e72e29), then your two additions (694beb5 supervise client readiness · 3541834 sidecar chmod). Exactly the pattern we hoped for.

What I dual-checked against the #2304 intent + your.additions

• Ingress contract is the agent-facing one (:9337 /v1/models), not management :3131 — matches Brad’s call-path review class and remove the “alive handle, dead ingress” hang.
• Debounce / streak keyed to runtime id, foreground closed-port vs watchdog consecutive failures, identity pin before take(), bounded stop + port-release wait, serve→client fail-safe documented — still hold.
• Only running relay-mesh agents re-arm; stopped agents stay stopped; sentinel-prefixed last_error clear-on-success only — still hold.
• Your Starting client path + independent ingress supervision + no agent-save hang on management pending — excellent operational catch; tests for pending status / failed startup reinforce it.
• Sidecar chmod 755 after cp on Unix — good packaging fix for the placeholder-mode trap.

Checks: Desktop/E2E/DCO/lint green from here; MERGEABLE, waiting on review protections.

Optional polish (your call — zero pressure; offering eyes only):

1. RestartRequired from the background watchdog — gated on already-running consumers, which is right. If users ever report surprise app restarts during first client spin-up after a cold install with many mesh agents auto-starting, a user-visible toast before request_restart() might soften the landing (keep the restart itself).
2. Ingress probe “success” — currently any successful /models counts as Live. If the SDK ever returns 200 with an empty/degraded model list while inference is wedged, you may want a secondary signal later; not blocking, just a future follow-up if multi-base dogfood sees it.
3. Watchdog backoff — errors double sleep (15→120s); Thor Ok(()) while still Debouncing resets to 15s, which mirrors “keep sampling while debouncing.” Intentional and fine; noting only so reviewers don’t reverse it thinking it’s thrash.

I will close #2304 as superseded by this PR (full cherry-pick + your ops layer). Happy to review further revisions, reproduce dogfood nits, or ship a small follow-up PR if you want a fix coded passively — or stay in review-only mode if you prefer to implement everything yourself.

Refs #2304 · #2062