build(nix): single-source the Rust toolchain and rustfmt edition

[loss-and-quick]

Summary

Two pieces of Rust configuration were hardcoded (or defaulted) in the nix layer instead of deriving from a single canonical source, so a bump had to touch two places or the two would silently drift. This PR single-sources both.

1. Toolchain version → rust-toolchain.toml

The pinned version lived in two places: nix/toolchain.nix (rust-bin.stable."1.95.0") and src-tauri/Cargo.toml (rust-version = "1.95.0").

• Put the pin in a conventional rust-toolchain.toml and read it from nix via rust-bin.fromRustupToolchainFile.
• Drop rust-version from src-tauri/Cargo.toml — nothing reads it (no MSRV job, no cargo config), and the pin already fixes the exact version for every builder. 1.95.0 now appears in exactly one place.
• Bonus: a bare rustup cargo outside the nix dev shell now picks up the same toolchain for free.

The android cross-build keeps working: fromRustupToolchainFile returns a re-overridable derivation, so rustAndroid = rustToolchain.override { targets = [...]; } still layers the android std on top (verified upstream in rust-overlay: fromRustupToolchain ends in pkg.override { … }, which stays overridable).

2. rustfmt edition → read from Cargo.toml

treefmt formatted Rust with treefmt-nix's default edition, which happened to match the workspace's 2024 — but nothing tied them together. On an edition bump cargo fmt (reads Cargo.toml) would move while the treefmt gate kept formatting as 2024, and the two would fight. Now programs.rustfmt.edition reads [workspace.package] edition from the root Cargo.toml, mirroring how the biome formatter already loads biome.json.

Scope note — CI dtolnay jobs intentionally not touched

I originally planned to also drop toolchain: stable from the dtolnay/rust-toolchain steps so they'd pick up rust-toolchain.toml. That premise is wrong: dtolnay/rust-toolchain's action.yml defaults toolchain to stable and does not read rust-toolchain.toml at all (its parse step errors if the input is empty — verified in the action.yml at the pinned commit). Unifying the rustup-based CI jobs onto this file needs a different setup action (e.g. actions-rust-lang/setup-rust-toolchain, which does read the file) — a broader change with its own behaviour (bundled caching), so it's a separate PR.

Affected layer

• frontend/ — React Web UI
• crates/ · src-tauri/ — Rust core / backend / Tauri desktop (toolchain pin + edition)
• module/ — Android installable zip
• scripts/ — build / release helpers
• CI / .github/
• Nix (nix/, flake.nix)
• Docs only

Verification

Nix / toolchain / formatter wiring only — no application logic changed:

• nix develop --command rustc/cargo/rustfmt/clippy --version — all resolve to 1.95.0 (nix builds rust-default-1.95.0 from the file)
• Both dev shells evaluate to valid derivations (default + android) — confirms rustAndroid's .override { targets } still instantiates
• cargo metadata parses after dropping rust-version
• nix build .#checks.x86_64-linux.treefmt — green (234 files, 0 changed); rustfmt edition now evaluates to 2024 read from Cargo.toml
• cargo clippy --workspace --all-targets -- -D warnings — clean

Notes for reviewers

Follow-up (separate PR): unify the 7 dtolnay/rust-toolchain steps across ci.yml, nightly.yml, release.yml, core-compat.yml onto rust-toolchain.toml via a file-reading setup action — this also pins them to 1.95.0 instead of floating stable (safe, since 1.95.0 is the pin every other builder already uses). Left out here to keep this change focused and the release pipeline untouched pending that decision.