feat(mesh): upgrade to mesh-llm 0.76.0-rc3 and recommend Qwen3.8 27B

[micspiral]

Upgrades every mesh-llm git dependency (buzz-relay + buzz-desktop) from v0.75.1 to v0.76.0-rc3, and makes Qwen3.8 27B Q4_K_M the curated pick for 64GB-class machines.

Why this rc, specifically, for Qwen3.8

Qwen3.8 could not be recommended on 0.75.1. Two upstream changes in this rc are correctness prerequisites, not polish:

• feat(topology): route Qwen3.8 identities to the qwen35 recurrent family Mesh-LLM/mesh-llm#1283 routes Qwen3.8 identities to the qwen35 recurrent family. Without it, Qwen3.8-... compacts to a string containing neither qwen35 nor qwen36, family resolution returns None, and the fallback classifies a hybrid recurrent model as dense attention-KV — so the planner treats SSM stages as freely-migratable KV.
• Update dependency @tanstack/react-virtual to v3.14.4 #1342 restores recurrent shared prefixes.
• refactor(desktop): centralize auxiliary panel shell #1343 adds Qwen3.8-27B-Q4_K_M to the compiled MODEL_CATALOG.

Catalog change

Because the large pick now exists in MODEL_CATALOG, the synthesized entry Buzz carried for the gemma-4-26B pick is deleted along with its _SIZE / _FILE / _DESCRIPTION constants — the entry is canonicalized from the upstream catalog instead. The retired gemma-4-26B alias is kept in canonical_curated_model_id so machines that already selected it keep resolving to a model id Mesh's OpenAI ingress accepts.

The small tier (gemma-4-E4B-it:Q4_K_M) and the 64GB rated-capacity boundary are unchanged.

Dependency resolution

Two transitive bumps were forced, both required to resolve at all:

• iroh 1.0.2 -> 1.0.3 (the rc requires ^1.0.3).
• libsqlite3-sys 0.30.1 -> 0.35.0 — the rc's mesh-llm-log-store needs rusqlite 0.37, and only one package in the graph may links = "sqlite3".

Verification

• cargo check -p buzz-relay — clean.
• cargo check --features mesh-llm (buzz-desktop) — clean.
• cargo test --features mesh-llm (buzz-desktop, full package) — 2611 passed.
• cargo fmt --check — clean.

Two failures predate this change; both reproduce on unmodified origin/main (verified by stashing this diff at f8692fa9b):

1. managed_agents::global_config::tests::inherited_shared_compute_translates_to_supported_agent_transport — asserts BUZZ_AGENT_MODEL == "auto", gets "mesh".
2. clippy -D warnings: items after a test module at managed_agents/restore.rs:528.

Scope of evidence

This is a compile-and-test-level upgrade. It is not runtime-verified against a live Qwen3.8 mesh node from this branch. I have separately verified Qwen3.8 27B Q4_K_M serving correctly (real completions, hybrid recurrent, 65 blocks, full_attention_interval 4) on a source build at mesh-llm main, but that was a mesh-llm binary, not this Buzz branch — someone should smoke a share-compute session before release.

Related open micspiral PRs

• fix(desktop): stop abandoning healthy mesh prefills at four minutes #6115 fix(desktop): stop abandoning healthy mesh prefills at four minutes — relevant and likely wanted alongside this. Qwen3.8 27B is a larger first load than the current default, so the four-minute prefill abandonment is more likely to bite after this upgrade, not less. Touches only relay_mesh.rs; no conflict with this PR.
• Mesh share-compute UX: sidebar card, topology #4697 Mesh share-compute UX: sidebar card, topology — touches the same share-compute feature area; may need a rebase on whichever of these lands first.

---

Includes #6115 (closed, folded in here)

Per Mic, #6115 fix(desktop): stop abandoning healthy mesh prefills at four minutes is closed and its content lands in this PR. Cherry-picked clean as a second commit, one file (managed_agents/relay_mesh.rs).

That fix is a genuine prerequisite for the Qwen3.8 default rather than an unrelated ride-along: buzz-agent's BUZZ_AGENT_LLM_TIMEOUT_SECS defaults to 240 s while MeshLLM's frontend gives a backend call 600 s, and mesh requests are stream: false — so a cold prefill is one silent request. Measured on an M5 Max serving Qwen3.8-27B Q4_K_M: an 88,318-token cold prompt returns HTTP 200 after 503 s. At the 240 s default the client abandons it at four minutes and retries with an escalated budget (240 -> 480 -> 960), piling load onto a box already prefilling the first attempt. Since this PR makes that exact model the 64GB-class default, shipping the upgrade without the fix would make the timeout more likely to bite, not less. Mesh is seated at 660 s; remote providers keep 240 s.

Combined-branch verification at 777426ba8: 2615 desktop tests pass (4 more than the upgrade commit alone — the fix's own tests), cargo fmt --check clean, same single pre-existing global_config failure noted above and nothing new.