Add nix flake build check to CI

[BradLugo]

Run 'nix flake check' and a full build on PRs. When the build fails
because vendorHash is stale, annotate flake.nix with the corrected hash
instead of leaving a bare hash-mismatch error.

This PR is part of a stack containing 5 PRs:

1. main
2. Fix nix flake build #247
3. "Add nix flake build check to CI" (this PR)
4. Document nix flake install in README #249
5. Auto-fix stale nix vendorHash on dependabot PRs #250
6. Enable dependabot updates for flake.lock #251

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (1)

• main

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Enterprise

Run ID: 2ab4082f-b9d4-447e-b2e9-2f32f0cc22f1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch blugo/nix-flake-check-ci

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[mclasmeier]

Thank you for your effort.
Let me Cc @msugakov on this one because I remember he was skeptical of Nix and we had an agreement that he won't be forced to touch Nix code when contributing to roxie -- introducing CI checks could be seen as a way to weaken this agreement.

@BradLugo , could you elaborate on under which circumstances a roxie contributor would need to touch Nix code?

[BradLugo]

which circumstances a roxie contributor would need to touch Nix code

With the change proposed here, any time a contributor makes changes to go.mod. Let me look through more examples of how other folks handle this and see what alternatives there are (currently thinking about some binary cache, but not sure how that would work).