CI hygiene: bring pre-existing workflow action versions up to date

[MJohnson459]

CI hygiene: bring pre-existing workflow action versions up to date

Branch: ci-action-versions (2 commits, 4 changed lines, workflows only)

What changed

1. actions/checkout v4 -> v7 in build.yml, claude.yml, claude-code-review.yml
   (the two image workflows were already on v7 from task 173).
2. prefix-dev/setup-pixi v0.9.0 -> v0.10.0 in build.yml.

Deliberately two commits so a cache or build-time regression is attributable to
one bump. Major-tag pinning style kept (v7, not a SHA), matching the repo.

Re-verified against the releases API on 2026-07-31

actions/checkout latest = v7.0.1 (major tag v7); prefix-dev/setup-pixi
latest = v0.10.0. The task's table was still accurate.

The setup-pixi breaking change is inert here — settled from source, not assumed

v0.10.0's only breaking change is the post-cleanup default flipping to false
(confirmed in src/options.ts: inputs.postCleanup ?? false at v0.10.0 vs
?? true at v0.9.0).

The task flagged the pixi cache as the plausible failure mode. It is not
reachable: in BOTH versions the cache is saved from the main step
(src/main.ts calls saveProjectCache/saveCache), and src/post.ts only
ever deletes .pixi, the pixi binary and the rattler dirs. Post-cleanup cannot
race or truncate the cache save in either version. Beyond that the runners are
ephemeral GitHub-hosted VMs, so skipping cleanup deletes nothing that survives
the job. Left at the new default rather than pinned back to post-cleanup: true.

Two genuine v0.10.0 changes do land, and both should be expected rather than
read as regressions:

• The cache is now split into separate project and global entries with
  new key formats, so the first build after this merges is a guaranteed
  one-time cache miss.
• The project cache key now hashes the pixi binary as well as the lockfile.
  build.yml pins no pixi version, so future pixi releases will invalidate the
  cache. That is correct — a conda env built by a different pixi should not be
  reused — but it means slightly more frequent cold builds.

The three-major checkout jump is safe for how this repo uses it

• v5 (Node 24): removes the "Node.js 20 is deprecated ... forced to run on
  Node.js 24" warning that every current run logs. v7's action.yml declares
  using: node24.
• v6 (credentials persisted to a separate file): irrelevant to submodule
  checkout here — both submodules are public HTTPS third-party repos
  (Slamtec/sllidar_ros2, PRBonn/kinematic-icp), so no credential is needed.
• v7 (blocks fork checkout for pull_request_target / workflow_run): none of
  the three workflows uses those triggers. They use push, pull_request,
  issue_comment, issues, pull_request_review, pull_request_review_comment.
• submodules is still a declared input in v7's action.yml, so
  submodules: recursive in build.yml is unaffected.

Verified

• Both bumped refs resolve to real published tags.
• All five workflow files parse as YAML; pre-commit (incl. check yaml) passed
  on both commits.
• Checked the remaining actions for staleness while here: claude-code-action@v1
  and all four docker/* actions in the image workflows are already on their
  latest majors. Nothing else to bump — no change made, scope kept to the task.

Baseline captured for the after-comparison

From the last green build.yml run on main (30628718063), per-step:

step	ubuntu-latest	ubuntu-24.04-arm
checkout	2s	2s
setup-pixi (warm cache)	21s	29s
Build	132s	118s
Test	122s	119s
Test fleet server	40s	40s
Post setup-pixi	3s	3s

Recent whole-run wall clock is 5.3-5.8 min. After the merge, expect: the
first run's setup-pixi step to be much longer than 21/29s (the one-time key
change above), subsequent runs to return to ~21/29s if the cache still hits,
and "Post setup-pixi" to drop from 3s to ~0s now that cleanup is skipped.

Outstanding

CI has not run — that needs a push, which I did not do. build.yml triggers on
pull_request, so opening the PR exercises both bumps on ubuntu-latest and
ubuntu-24.04-arm, including submodule checkout. The remaining check is that
the second run on the branch shows setup-pixi back at ~21/29s, confirming the
cache still hits. The two Claude workflows are only exercised when triggered, so
their checkout bump is confirmed by an actual bot run on the PR rather than by CI.