build: make mesh-llm opt-in for dev/staging to speed up iteration

[wesbillman]

Problem

just dev and just staging hardcoded tauri dev --features mesh-llm, and staging also ran ensure-mesh-native-runtime.sh (builds llama.cpp via cmake on cache miss). That forced the heavy mesh path on every iteration build — the two commands humans and agents run most.

Measured cost: desktop tauri deps without mesh-llm = 594 crates; with = 1014. That's +420 crates (~71%) plus a C/C++ native runtime build on every dev/staging run. (Pinky's run on a slightly different graph measured 720 → 1051, +331 — exact number varies by environment, the savings are real either way.)

Change

Add a mesh := "" toggle, off by default:

• just dev / just staging — fast, no mesh-llm, no native-runtime prep.
• just mesh=1 dev / just mesh=1 staging — full mesh build for testing compute-sharing features.

mesh-llm is fully optional in code (default = [] in desktop/src-tauri/Cargo.toml; every mesh Tauri command has a #[cfg(not(feature = "mesh-llm"))] stub returning "mesh-llm feature not enabled"), so the default build is a complete, working app minus the mesh compute UI.

How this lines up with CI / release

This brings dev/staging in line with what CI and release already do:

• CI (ci.yml) runs bare pnpm tauri build (no --features mesh-llm); it only prebuilds/caches the llama native libs separately, keyed by mesh rev.
• Release (release.yml:175-187) also builds pnpm tauri build with no --features mesh-llm — it sets the LLAMA_STAGE env + caches native libs but does not pass the cargo feature. So the shipped desktop DMG today compiles mesh-llm OFF (mesh commands are stubs in production).

⚠️ Correction to my earlier claim: I previously said release keeps --features mesh-llm — that's wrong. It doesn't. Credit to Pinky for catching it. This doesn't change the iteration-speed fix (default dev/staging matching CI/release is the right call), but it surfaces a separate product question for @wes: if shipped Buzz desktop is supposed to include Mesh by default, the release build is missing the feature flag — that's its own bug/decision, out of scope here.

Full mesh build still available via

• just mesh=1 dev / just mesh=1 staging
• just mesh-e2e-hardware (unchanged)

Follow-ups (not in this PR, intentionally scoped out)

• Update mesh local-build docs + the runtime error text so they point at the explicit mesh=1 path, not plain just staging (per Pinky).
• The product question above (does shipped desktop want mesh on?).
• CMAKE_POLICY_VERSION_MINIMUM=3.5 in dev/staging recipes to unbreak local desktop builds on newer CMake.
• Pre-push hook returns non-zero on a relay-dependent e2e step when no relay is running locally.

Validation

• just --list parses; recipes intact.
• Empty-array + set -u footgun handled with ${FEATURES[@]+"${FEATURES[@]}"}; verified under macOS bash 3.2.57 for both mesh on and off.
• cargo check of the desktop tauri crate without mesh-llm compiles green — stubs are complete.
• Pre-commit (fmt/lint) and the test suite (rust + desktop + tauri + mobile) pass locally.