ci(nix): only run Nix CI on flake and packaging changes

[davidbudnick]

Summary

Stop running the two-arch Nix build on ordinary feature PRs. Nix CI now triggers on PRs only when the flake or packaging/linux actually changes. The Monday job still catches Cargo/source drift.

Why

Nix CI was matching Cargo.toml, Cargo.lock, crates/**/Cargo.toml, build.rs, icons, and the example config. That is most feature PRs. Each run is a full nix build on x86_64 and aarch64 (typically 17–20 minutes each, ~40 billed minutes per push). The workflow already has 658 runs. Linux cargo CI already compiles those same Cargo.toml changes.

Residual risk

A PR that adds a new native/system dependency without touching packaging/linux stays green until the Monday cron (or a manual workflow_dispatch). That is the tradeoff for not rebuilding Nix on every crate bump.

Test plan

• Confirm this PR itself still runs Nix CI (it touches .github/workflows/nix.yml)
• Confirm a HID/GUI-only PR no longer queues Nix CI after this merges

[greptile-apps]

Greptile Summary

Narrows pull-request triggers for the two-architecture Nix build while retaining scheduled and manual validation.

• Removes Cargo manifests, lockfile, build scripts, icons, and example configuration from the pull-request path filter.
• Continues triggering for flake, Nix packaging, and relevant workflow changes.

Confidence Score: 5/5

The PR appears safe to merge, with the delayed detection of source-driven Nix failures explicitly accepted as its intended tradeoff.

The retained filters still run Nix CI for this workflow and relevant Nix packaging changes, while scheduled and manual execution continue to cover deliberately deferred source-integration drift.

Important Files Changed

Filename	Overview
.github/workflows/nix.yml	Narrows Nix CI pull-request path filters as documented while preserving validation for Nix packaging and workflow changes.

_{Reviews (1): Last reviewed commit: "ci(nix): only run Nix CI on flake and pa..." | Re-trigger Greptile}