ci(linux): enable mesh-llm feature in Linux release and canary builds

[tlongwell-block]

Summary

Official Linux desktop packages (.deb / AppImage) are built without --features mesh-llm, so they ship the mesh_llm_stubs backend and Settings → Compute always fails with mesh-llm feature not enabled. This PR adds the feature flag to the two Linux build commands:

• release.yml → release-linux job
• linux-canary.yml → canary build

That's the whole diff — 2 lines. Fixes #3788 (Linux); see also #3841 (dup with UI-gating PR #3914) and the Windows twin #2836/#3223.

Why no native prebuild step (unlike the macOS job)

The macOS job carries Metal llama prebuild/cache steps from #798. Linux doesn't need an equivalent:

• mesh-llm-host-runtime is compiled with dynamic-native-runtime and installs the recommended runtime on first use (verified by sha256 checksum over HTTPS; upstream's signature verification path is not yet implemented — default policy is RequireChecksum, per mesh-llm-runtime-install/src/lib.rs) (desktop/src-tauri/src/mesh_llm/mod.rs — initialize_mesh_native_runtime), so release builds work on clean machines without bundling llama.cpp.
• Upstream publishes Linux x86_64/aarch64 runtime bundles for the pinned v0.74.0 line, and scripts/ensure-mesh-native-runtime.sh already maps meshllm-native-runtime-linux-x86_64-cpu / linux-aarch64-cpu for local/e2e use.
• The unmerged branch micn/mesh-node-download (96f29417a) treats even the macOS prebuild steps as removable dead weight for the same reason.

Background

The omission is historical drift, not a decision: Linux packaging predates the mesh feature flag (#693), mesh became opt-in for build-cost/reliability reasons (#823, #1183), and #1221 re-enabled it for releases by editing only the macOS build line. release-linux and the later linux-canary copy were never revisited.

The mesh shutdown hard-exit/relaunch path is gated all(mesh-llm, target_os = "macos") because ggml/Metal destructors abort on macOS; ordinary mesh shutdown (shutdown_mesh_runtime) is cross-platform, so Linux falls through to the generic path.

Validation

• ./bin/cargo check --manifest-path desktop/src-tauri/Cargo.toml --features mesh-llm green at base 2c0ac2467 (feature graph compiles at the pinned v0.74.0 line)
• Linux canary run with this change: AppImage/.deb build succeeds and binary contains real mesh_llm symbols (not mesh_llm_stubs)
• Installed package: cold-start → Settings → Compute → runtime download → serve → clean shutdown

The last two need a Linux run/host. Note (from review): linux-canary.yml is workflow_dispatch-only and its Require main step rejects non-main refs, so the canary cannot run on this branch pre-merge — and .github/workflows/** matches no ci.yml paths-filter, so this PR's own CI does not exercise the changed lines. Validation sequencing is therefore merge → dispatch linux-canary on main → live-package pass, with a trivial 2-line revert as the escape hatch.

[tlongwell-block]

Hard-review verdict at exact head f7c10cdbc956999fc66f748acaed444615bac4c1: no static blocker found, but I would not merge until an exact-head Linux package build and installed-package runtime smoke are complete.

What I verified:

• Diff is exactly the two intended --features mesh-llm additions.
• In the workflow's digest-pinned ubuntu:24.04 image (sha256:4fbb...), on linux/amd64, cargo check --manifest-path desktop/src-tauri/Cargo.toml --features mesh-llm completed with the workflow's listed build dependencies and Hermit Rust 1.95. This compiled Iroh, Mesh host/runtime/install crates, and Buzz Desktop; no additional Linux system or linker dependency surfaced. (Sidecar placeholders were supplied solely because the Tauri build script requires the paths.)
• mesh-llm-host-runtime remains selected with dynamic-native-runtime; Buzz initializes that runtime on first use. The native runtime is therefore not expected in the Tauri bundle. The Windows MinGW DLL work is target-specific and does not imply an analogous Linux bundle requirement.
• desktop/scripts/fix-appimage.sh operates only on the produced AppImage's infrastructure libraries and wraps usr/bin/buzz-desktop; it neither enumerates nor removes downloaded Mesh runtime files. I found no static collision.
• shutdown_mesh_runtime is feature-gated, not macOS-gated, and is called before ordinary Linux exit. The _exit/relaunch branches are narrowly macOS-only for Metal destructor behavior.

Validation gap:

• Current PR checks are green, but none run the changed Linux release/canary build commands.
• No Linux Canary run exists for this branch/SHA, and the workflow currently has a Require main guard, so it cannot directly be dispatched on the PR branch without a temporary validation mechanism.
• Still required: produce .deb + AppImage at this exact head, install/cold-start each, open Settings → Compute, exercise signed runtime download and model serving, then verify clean shutdown.

Minimalness 10/10, elegance 10/10, static correctness 9/10; shipping confidence remains conditional on the package/runtime proof above.