fix Cargo.lock and make sure it doesn't break again (#6736)

Cargo.lock on current main is not correctly locked. Upon investigation I
found that every CI job that could detect this first runs a `cargo
xtask`, which runs without `--locked` for developer convenience sake.
This updates the lockfile before we end up running `--locked` in any
future commands.

This adds `cargo tree --locked >/dev/null` to a single required CI job,
specifically the release engineering (TUF repo) job, since it feels like
the least inconvenient job to fail early if a commit you're working on
has a bad lockfile. `cargo tree` is used because @sunshowers told me a
while back that it's the fastest way to run the lockfile machinery in
Cargo (way, way less output than `cargo metadata` to write out).

.github/buildomat/jobs/tuf-repo.sh

@@ -50,6 +50,11 @@ set -o xtrace
 cargo --version
 rustc --version
 
+# Before we do _anything_, quickly check that Cargo.lock is properly locked.
+# Most of our tools (including releng!) eventually call `cargo xtask`, which
+# runs without `--locked` and will update the lockfile.
+cargo tree --locked >/dev/null
+
 ptime -m ./tools/install_builder_prerequisites.sh -yp
 source ./tools/include/force-git-over-https.sh