Tooling: move rust-toolchain.toml to the workspace root

`apps/desktop/rust-toolchain.toml` was only in scope when rustup/cargo was invoked from inside `apps/desktop/`. That broke for the workspace's other two members (`crates/fsevent-stream`, `crates/index-query`) — they've been silently using whatever default toolchain rustup happened to have installed, not the pinned 1.95.0. And it broke the release workflow yesterday (`db58ff6b`'s build failed because the repo-root `rustup target add x86_64-apple-darwin` step touched a different toolchain than `pnpm tauri build` did inside `apps/desktop/`).

The workspace `Cargo.toml` already lives at the repo root, `target/` already lives at the repo root, and rustup expects the toolchain pin next to the workspace `Cargo.toml`. Moving the file there makes the whole tree see a single, consistent toolchain regardless of which directory you `cd` into.

- `git mv apps/desktop/rust-toolchain.toml ./rust-toolchain.toml`. Comment in the file updated to reflect the new location (no longer needs the "release.yml runs from repo root" footnote).
- `release.yml`: drop the standalone `rustup target add x86_64-apple-darwin` step. The pinned channel now declares both targets, so rustup auto-syncs them the first time it resolves the toolchain. One source of truth.
- `ci.yml` paths-filter: the `rust:` group's only Rust-trigger paths were `apps/desktop/src-tauri/**` and the old `apps/desktop/rust-toolchain.toml`. Broaden to also catch `crates/**`, the workspace `Cargo.toml` / `Cargo.lock`, and the new `rust-toolchain.toml` at root — any of those affect Rust builds and should fire the Rust job.

Verified: `rustup show active-toolchain` resolves to `1.95.0-…(overridden by /Users/.../rust-toolchain.toml)` from the repo root AND from `crates/fsevent-stream/` (which previously got `stable` or whatever the user had).

Author: vdavid

.github/workflows/ci.yml

@@ -37,7 +37,10 @@ jobs:
           filters: |
             rust:
               - 'apps/desktop/src-tauri/**'
-              - 'apps/desktop/rust-toolchain.toml'
+              - 'crates/**'
+              - 'Cargo.toml'
+              - 'Cargo.lock'
+              - 'rust-toolchain.toml'
             svelte:
               - 'apps/desktop/src/**'
               - 'apps/desktop/static/**'

.github/workflows/release.yml

@@ -42,10 +42,6 @@ jobs:
         run: pnpm exec svelte-kit sync
         working-directory: ./apps/desktop
 
-      - name: Install x86_64 Rust target
-        if: matrix.arch != 'aarch64'
-        run: rustup target add x86_64-apple-darwin
-
       - name: Import Apple certificate
         env:
           APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }}

apps/desktop/rust-toolchain.toml rust-toolchain.tomlapps/desktop/rust-toolchain.toml renamed to rust-toolchain.toml

@@ -9,9 +9,8 @@ channel = "1.95.0"
 # the runner picks them up automatically — without this, every CI Rust job
 # fails at the rustfmt step.
 components = ["rustfmt", "clippy"]
-# Release builds need both targets for the universal binary, and the standalone
-# `rustup target add x86_64-apple-darwin` step in `release.yml` runs from the
-# repo root (not `apps/desktop`), so it adds the target to a *different*
-# toolchain than the pinned channel `pnpm tauri build` actually uses. Declaring
-# the targets here makes rustup sync them with the pinned channel automatically.
+# Release builds the universal binary from both arch targets, so the pinned
+# channel needs both available. Listing them here makes rustup auto-sync them
+# the first time the toolchain is resolved; no separate `rustup target add`
+# step is needed in CI.
 targets = ["aarch64-apple-darwin", "x86_64-apple-darwin"]