.github/workflows/update-flake-lock.yml updates Cargo.lock without checking compatibility

[eureka-cpu]

Describe the bug

This commit: a56fc0f was generated by the CI updater. The nixpkgs version used in that updater is whatever is the latest available version. In this case the latest available version of cargo in that version of nixpkgs has standardized a new way of parsing Cargo.lock files, causing downstream users breakage if their nixpkgs version is not latest.

To Reproduce

Steps to reproduce the behavior:

1. Include system-manager as an input to a flake, and have it follow nixpkgs at an earlier release.
2. Build will fail stating that it requires an experimental feature flag in order to compile Cargo.lock version 4 (-Znext-lockfile-bump)

Expected behavior

The project compiles for the version of nixpkgs the user has.

System information

x86_64-linux on version 0.1.0

Additional context

Probably the best way to handle this would be to always check against the most recent stable release at least before merging the update from the CI updater. Could even have the updater do the check prior to opening a PR. Using a rust-toolchain.toml from the root and creating a devShell with that would also be helpful for checking, since it would ensure any contributor who is working on the project will spot version related bugs more easily. It just so happens that my system's nixpkgs' cargo version is 1.82 and so I was able to spot the bug and find the commit where it changed.

[r-vdp]

This is actually renovate that's updating dependencies. It doesn't use nix.

I'm not sure how it determines the version of rust it uses. We might need to add something to Cargo.toml or such to constrain it.