ci: add Windows and Linux canary workflows with caching

[wpfleger96]

Adds windows-canary.yml and linux-canary.yml — workflow_dispatch jobs that produce unsigned installable artifacts (.exe NSIS installer, .deb + .AppImage) from any ref without touching the release pipeline. Also retrofits signed-macos-canary.yml with Rust and pnpm caching so all three canary builds warm quickly on repeat dispatches.

What this adds

windows-canary.yml — windows-latest runner, rust-toolchain.toml in the repo root pins the toolchain via preinstalled rustup (rustup target add to register the MSVC target), pnpm install --frozen-lockfile, sidecars cargo build --release, pnpm tauri build --bundles nsis with createUpdaterArtifacts:false. Uploads the NSIS .exe as artifact buzz-windows-canary-<source-sha>, 7-day retention. No mesh-llm (release-windows doesn't build it).

linux-canary.yml — same ubuntu:22.04 container as the release job, same apt deps block, pinned appimagetool 1.9.1 + type2-runtime 20251108, hermit, mold, just desktop-install-ci, sidecars, pnpm tauri build --bundles deb,appimage. Runs fix-appimage.sh without signing env vars (the script detects their absence and skips re-signing; repacking still removes the Mesa/GLib/GStreamer conflict libs). Uploads .deb + .AppImage as buzz-linux-canary-<source-sha>, 7-day retention.

signed-macos-canary.yml — adds Swatinem/rust-cache (workspace root + desktop/src-tauri) and the pnpm store restore/save pattern. The existing mesh-llama cache is unchanged.

Design decisions vs. signed-macos-canary.yml

The macOS canary has a Require main guard because it runs OIDC signing/notarization — the OIDC token scope is tied to the ref. The Windows and Linux canaries are contents: read, unsigned, and zero-secrets, so building arbitrary refs is safe and is the entire point: pre-merge Windows/Linux testing without local toolchains.

Caching rationale

• Rust: Swatinem/rust-cache with workspaces: . \n desktop/src-tauri covering both the sidecar --release build and the Tauri build. shared-key scoped to <platform>-canary-release — canary runs warm each other without colliding with CI's debug-profile keys (CI Windows runs clippy/check, not --release).
• pnpm: explicit store restore/save pattern from ci.yml:149-196. Restores are unconditional (a cold miss is safe). Saves are conditional: workflow_dispatch executes on the dispatch ref, so github.ref/github.sha stay main-scoped even when inputs.ref checks out a feature branch. Without a guard, a dispatch from main with a non-main inputs.ref and an unchanged lockfile would write into the main-scoped pnpm cache under the same key as CI — a cache-poisoning path. The actions/cache/save step and the rust-cache save-if both require github.ref == 'refs/heads/main' && inputs.ref == 'main'. signed-macos-canary.yml is unaffected (its main-only guard makes all saves trusted).
• mold: rui314/setup-mold on Linux to reduce link time, matching the Linux Rust CI jobs.
• timeout-minutes: 60 on all three — generous enough for the cold path.

Artifact provenance

github.sha stays the dispatch-ref (main) SHA regardless of inputs.ref. A "Capture source SHA" step immediately after checkout resolves git rev-parse HEAD into a step output; artifact names and log lines use that resolved SHA so an artifact built from a feature branch is unambiguously named.

Zizmor hygiene

All three workflows: every action pinned by full commit SHA (matching ci.yml/release.yml pins), persist-credentials: false on checkouts, top-level permissions: contents: read, no ${{ }} interpolation directly in run: bodies (env-var indirection throughout), if: github.repository == 'block/buzz' on jobs, ref input flows through actions/checkout ref:.