chore: mesh upgrade, clean up legacy special case code, simplify model selection for mesh

[micspiral]

Shared compute now has exactly two model choices: MeshLLM's virtual mesh
model, or a model you name. Buzz picks between them in one place, and
buzz-agent no longer knows meshes exist.

What changed

• MeshLLM v0.74.0 → v0.75.1. v0.75.0 added degrade_to_single_model, so a
  model=mesh request is answered by one served model when there is no
  committee to form, instead of failing. v0.75.1 adds Mesh-LLM#1196, which
  skips stale pre-0.75 runtime cache entries rather than aborting startup on
  them — without it, anyone who had run mesh on 0.73/0.74 could not start.
• Deleted the client-side mesh catalog probe. buzz-agent used to poll
  /v1/models (5s TTL, 30s cooldown, two-observation debounce) to decide
  whether mesh was safe to send. MeshLLM now decides per request, so the
  polling, its hysteresis, and its 503 fallback are gone.
• One mapping point. relay_mesh_wire_model() turns the stored value into
  a wire name: auto becomes mesh, a named model passes through. The spawn
  env, the ACP harness, and the readiness probe all use it, so they cannot
  disagree — previously BUZZ_ACP_MODEL and the probe both said auto, a name
  the mesh does not advertise.
• Removed the nostr-relay-pool advisory exception. ci(security): allow retired relay pool advisory #5404 allowed
  RUSTSEC-2026-0243 "after mesh-llm migrates to nostr-sdk >= 0.45". v0.75.1
  does, so the retired crate is gone from both lockfiles and the exception
  would only mask a future advisory for it.
• Deleted scripts/ensure-mesh-native-runtime.sh and its six justfile call
  sites. It built llama.cpp from source into the runtime cache; the app already
  downloads the signed release runtime itself, and CI never called it.

Why it is better

−639 lines of Rust. Availability is decided by the node that knows the
answer, per request, instead of by a client cache that could be stale for up to
30 seconds. A second worker joining now takes effect on the next request rather
than after two confirming probes.

Behaviour change

A 503 on an explicit mesh request takes the ordinary transport retry under
the same model instead of failing over to a second one — there is no second
model to fail over to now. MoA repairs partial committee results internally
before it reaches that point.

Validation

crates/buzz-relay/examples/mesh_agent_e2e.rs now sends mesh where it
previously sent auto or the physical model id, so no leg was covering what
Buzz actually puts on the wire. 4/4 on gemma-4-E4B, gemma-4-26B-A4B, and
Qwen3-8B — including a real ACP tool call through mesh into buzz-dev-mcp,
asserted by reading the written file back off disk.

Hand-tested in the desktop app on both gemma-4 sizes: picked Auto, agent logged
model_id=mesh, replied in channel.

Not covered

A committee that forms and then loses a worker returns 502, and that needs two
workers to reproduce — not testable on one machine.

[wesbillman]

Reviewed on Wes's behalf at 8e3b15019d09a17de0cd21144ac62b366f7ac5d7.

No blocking findings.

I traced the effective provider/model resolution through EffectiveAgentConfig::relay_mesh_model_id, spawn_agent_child, the mesh process env, BUZZ_ACP_MODEL, and wait_for_mesh_inference. Stored auto/legacy blank consistently becomes the wire model mesh; explicit model names stay explicit. Linked definitions and global inheritance continue to use the existing effective-config precedence rather than stale instance bytes.

I also checked the removed buzz-agent catalog/hysteresis/fallback path, all six deleted Justfile pre-seed call sites, both dependency manifests/lockfiles, the retired advisory exception, and the focused e2e changes. The removed fallback's behavioral change is accurately disclosed: terminal committee failure retries the same mesh route rather than changing models. MeshLLM 0.75's single-worker degradation makes the old eligibility fallback obsolete, while an already-formed committee losing a worker remains a known two-worker failure case.

Validation evidence: git diff --check passed locally on the exact head; all GitHub checks are green, including Unit Tests, Rust Lint, Desktop Core, Security, Relay E2E, and Relay-Driven Mesh Lifecycle Smoke. I did not duplicate the broad CI suite locally.

One non-blocking caveat: BUZZ_ACP_MODEL remains intentionally user-overridable through layered env, so “cannot disagree” applies to Buzz's derived defaults, not an explicit power-user override.

[wpfleger96]

🤖 Reviewed at head 8e3b150 — no blocking concerns, but I think the auto → mesh translation at the top of wait_for_mesh_inference (desktop/src-tauri/src/commands/mesh_llm.rs:603) left the catalog-visibility check just below it slightly stale.

The branch at line ~632 still compares model_id == crate::mesh_llm::AUTO_MODEL_ID, but after the translation model_id can only ever be mesh or a named model, so that comparison looks unreachable now. The practical effect: mesh-llm 0.75.1 only advertises the virtual mesh model in /v1/models when there are ≥2 non-mesh models (should_advertise_virtual_mesh in moa_gateway/context_selection.rs), so on a single-worker mesh with stored auto, model_ever_visible stays false for the whole wait. If readiness then times out (e.g. the lone worker is still loading weights), the failure gets classified as CatalogNeverSynced — the "network path problem" message — when RoutingNeverCompleted ("found the host, try again shortly") is the truth. Before this PR the any-model-counts rule for auto classified that case correctly.

The happy path is fine — the chat probe sends model: mesh and degrade_to_single_model handles it server-side — so this is only about which error message a user sees on a readiness timeout. I think the fix is a one-liner: compare against managed_agents::RELAY_MESH_VIRTUAL_MODEL_ID instead, keeping the same "delegated choice — any advertised model counts" semantics keyed on the translated name. That would also stop the failure text from quoting "mesh" at a user who picked "Auto".

Happy to be corrected if the single-worker catalog behaves differently in practice.

[micspiral]

🤖 Fixed in c3bcdea, refactored in d3cdb0e.

Confirmed against a live single-worker node: /v1/models lists only the served model, no mesh, so model_ever_visible did stay false for the whole wait as described.

• comparison now keys on RELAY_MESH_VIRTUAL_MODEL_ID, per the suggestion
• predicate extracted as mesh_catalog_shows_model so the rule is testable; 4 tests, verified failing with the old comparison restored
• failure copy now names the caller's model, so Auto is not reported as "mesh"
• readiness moved to commands/mesh_readiness.rs — the fix pushed mesh_llm.rs over the 1000-line ratchet

[michaelneale]

thanks @wpfleger96 @wesbillman - patched that up, good for another review (and hand tested of course)

[wesbillman]

Re-reviewed on Wes's behalf at exact head d3cdb0efb0bebf4f646425ad065bb4c6f04b2c7b after the readiness-diagnosis fix. Approved.

The prior review concern is resolved correctly. wait_for_mesh_inference still translates the stored model to the actual wire model before both catalog and chat probes, but mesh_catalog_shows_model now keys delegated-choice behavior on the translated virtual mesh identifier. Thus a non-empty single-worker catalog counts as synced even though MeshLLM does not advertise the virtual model until a committee can form; named models still require an actual normalized match. Timeout copy retains the caller's stored name, so Auto users are no longer shown the internal mesh wire identifier.

I verified the extraction into commands/mesh_readiness.rs is behavior-preserving apart from pub(crate) visibility, and that all seven readiness tests moved with the code. The regression cases cover virtual-model/non-empty catalog, empty catalog, named-model positive/negative matching, @main normalization, failure classification, and distinct actionable copy.

No blocking findings. git diff --check passes at this exact head, the working tree is clean, and every applicable GitHub check is green, including Rust Lint, Unit Tests, Desktop Core, Security, cross-compiles, Relay E2E, and Relay-Driven Mesh Lifecycle Smoke. I did not duplicate the broad CI suite locally.

[wesbillman]

Reviewed exact head d3cdb0efb0bebf4f646425ad065bb4c6f04b2c7b adversarially. Changes requested.

The runtime mapping itself is coherent: stored auto/blank maps to mesh through the shared helper for readiness, buzz-agent transport, and ACP bootstrap; named models pass through. I traced effective-config precedence, existing-runtime recovery, serve/client restoration, request retries, ACP session model negotiation, the extracted readiness module, and the MeshLLM 0.75.1 dependency/security changes.

Blocker — deleting the native-runtime preparer makes the documented hardware test commands self-deadlock on a clean checkout. The PR removes scripts/ensure-mesh-native-runtime.sh and all Justfile invocations, but the first two commands still explicitly refuse to initialize/install when the current runtime is absent:

• Justfile:355-358 runs mesh_serve_client_smoke directly.
• mesh_serve_client_smoke.rs:44-52 checks cache.installed() and bails with “run just mesh-e2e-hardware to prepare it” — the very command currently executing.
• Justfile:362-365 has the same issue for admission, whose mesh_admission_smoke.rs:57-66 bails and tells the user to run the equally broken hardware command.
• mesh-e2e-confidence starts with those same two examples, so it never reaches mesh_agent_e2e, the only example here that actually calls initialize_host_runtime() without pre-rejecting a missing cache.

Thus the claim that the app/runtime installs the signed release artifact may be true for the desktop path, but it does not preserve these standalone Just targets. Existing warm developer caches and CI cannot detect this clean-machine failure. Fix the examples/recipes to invoke the SDK-owned installer (or otherwise bootstrap before checking), and test the no-current-runtime path.

git diff --check passes at this head; CI is green, but it does not exercise this hardware-gated clean-cache lifecycle.

[michaelneale]

thanks @wesbillman - I was hoping to drop those just targets, as I didn't think they wer eneeded, but looks like I messed something up.

[micspiral]

🤖 Fixed in fbba6de.

Confirmed the blocker: both examples bailed immediately before the initialize_host_runtime() call on the next line, which installs the signed runtime when the cache has none. Guard removed from both; mesh_agent_e2e never had one, which is why it kept working.

Verified on a genuinely cold cache — every entry moved aside first, so the only runtime present afterwards was the one the run installed:

just mesh-e2e-hardware
  cache: (empty) -> 0.75.1, downloaded not built
  [smoke] PASS: serve→client→inference proven over mesh

just mesh-e2e-admission
  [admission] PASS 1/3: trusted client admitted, sees routed model
  [admission] PASS 2/3: trusted client inference routed over mesh: "PONG"
  [admission] PASS 3/3: non-member saw gossip but inference was rejected: 503

mesh-e2e-confidence runs those two plus mesh_agent_e2e, so it is unblocked by the same change.

has been adjusted - added the right things back in, and they work