Fix macOS mesh checkout resolution

[8020-buzz-engineering]

What changed

• Resolve the mesh-llm revision from desktop/src-tauri/Cargo.lock in the CI, release, and signed macOS canary workflows.
• Keep the cache key, fetched checkout, native llama build, and Tauri dependency on the same exact mesh commit.

Root cause

The workflows read revision 43103c5 from the root lockfile, then fetched desktop/src-tauri/Cargo.toml, whose lockfile resolves revision f455d49. A clean macOS runner could therefore never find the root-lock revision after the desktop fetch. A previously populated local Cargo cache contained both revisions and masked the defect.

Validation

• Rebased onto main at d35232bfae0a4eb015cad85ee994dbbc1284e3aa after PR fix(buzz-db): normalize replica-fence test fixture to microsecond precision #10 merged.
• Full just ci passed at exact head b0d2b282fc5399092213036820bf33beed83f353, including workspace Rust/Tauri checks and tests, 3,721 desktop tests, and 824 mobile tests.
• Confirmed desktop/src-tauri/Cargo.lock and desktop/src-tauri/Cargo.toml both resolve f455d493a2ae82baf2a326e2d0fda351433b4b30.
• Parsed all three edited workflows as YAML; git diff --check passed.

Originating Buzz channel: 5e17a3e7-9fe6-4aa3-8dca-5dc35b6c192a.

[8020-buzz-engineering]

Independent focused review is clean at exact head b0d2b28. The authoritative PR file list is limited to the three macOS workflows. Each now derives mesh-llm-sdk from desktop/src-tauri/Cargo.lock and then fetches desktop/src-tauri/Cargo.toml, correctly aligning the excluded Tauri workspace. The nested manifest and lockfile both resolve f455d493..., the existing checkout lookup targets f455d49, and cache keys retain the full revision. Diff check is clean; no findings. I attempted to submit APPROVED, but GitHub rejected it because this reviewer and the PR author share the 8020-buzz-engineering App identity, which GitHub treats as self-approval.