feat(nix): add Nix flake for desktop app

[wanderer]

Summary

• Adds a Nix flake that builds the Tauri v2 desktop app
• Uses the canonical nixpkgs pattern: cargo-tauri.hook + fetchPnpmDeps + pnpmConfigHook
• Builds the pnpm monorepo frontend, then the Tauri Rust binary with embedded frontend assets

Usage

nix build           # build the package
nix run             # run OpenConcho

Tested

• Verified build succeeds on x86_64-linux (nixpkgs-unstable)
• Produces binary, .desktop file, and app icons

[offendingcommit]

Thanks for this — the flake itself is clean and uses the canonical nixpkgs Tauri pattern (cargo-tauri.hook + fetchPnpmDeps + pnpmConfigHook) correctly. We're happy to support Nix as a documented use-case, but it needs to live inside our existing ecosystem without rotting, so I'm requesting a few changes before merge.

Could you share the justification / audience? Our release.yml already ships desktop binaries for macOS, Windows, and Linux via semantic-release + tauri-action. This flake covers platforms.linux only — a subset of what we already publish. Knowing who consumes the flake (NixOS install? reproducible dev shell?) helps us decide how much surface to commit to maintaining.

Changes requested:

1. pnpmDeps hash will rot silently. The fixed-output hash pins pnpm-lock.yaml and invalidates on every dependency bump — which is frequent here under semantic-release. We have no Nix job in CI, so this breaks with no signal. Please add a nix flake check (or nix build) step to .github/workflows/ci.yml so the hash is verified on PRs. Without that, the flake is an untested build path the moment the lockfile moves.

2. Add a devShell. A package-only flake helps a narrow audience that already has release binaries. A nix develop shell pinning the toolchain (node, pnpm_10, Rust, the GTK/webkit deps) is the part that earns its place in the repo and helps contributors. If the goal is reproducible dev envs, this is the high-value piece.

3. version = "0.8.0" duplicates package.json. Minor (it only labels the store path, doesn't gate the build), but it'll mislabel after the next release. Please read it from package.json or drop it from anything load-bearing so it can't drift.

4. Optional but ideal: add aarch64-darwin so the flake covers the platform several of us actually develop on.

Net: wire it so a single dependency bump can't silently break it, give it a devShell, and we'll gladly carry Nix as a supported path. Appreciate the contribution!