Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/prepare-release.yml:
- Around line 265-274: The cache key in the "Cache cargo" step uses `${{
matrix.target }}` but the prepare job has no matrix, so `matrix.target` is
empty; update the `key` expression in the "Cache cargo" step (the step named
"Cache cargo" that contains the `key:` entry) to remove or replace
`matrix.target` (e.g., use `${{ runner.os }}` or a static token) so the cache
key is stable — e.g. change it to use just `${{ runner.os }}-cargo-${{
hashFiles('**/Cargo.lock') }}` or an equivalent single-job-safe value.
- Around line 350-364: The `Prepare GitHub Release` step runs `gh release create
${TAG_NAME}` unauthenticated; set the GitHub token for the step so `gh` can
authenticate. Update the step (named "Prepare GitHub Release") to provide
GITHUB_TOKEN (or GH_TOKEN) from the workflow secrets (e.g. secrets.GITHUB_TOKEN)
in the step's env, so the existing `gh release create ${TAG_NAME} --title
"${TAG_NAME}" --notes "${RELEASE_NOTES}" ...` invocation can succeed.

In @.github/workflows/release.yml:
- Around line 285-294: The cache key in the "Cache cargo" step uses ${{
matrix.target }} but the release job has no matrix, so replace the undefined
matrix reference with a stable identifier (e.g. remove matrix.target and use ${{
runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }} or use an explicit job
env/var like ${{ env.TARGET }} if you introduce one); update the cache key in
the "Cache cargo" step and any other places referencing matrix.target in the
release job (and mirror the same change you applied in prepare-release.yml) so
the key no longer relies on a non-existent matrix.

---

Outside diff comments:
In @.github/workflows/prepare-release.yml:
- Around line 277-291: The cache step named "Cache oxide build" currently uses a
key containing "${{ matrix.target }}" which causes cache fragmentation; update
the step so the "key" for the actions/cache entry removes the matrix.target
segment and matches the cargo cache fix (e.g., use "${{ runner.os }}-oxide-${{
hashFiles('./crates/**/*') }}" or the same stable key pattern used in the cargo
cache step), keeping the same "path" and "lookup-only" fields and leaving
restore/restore-keys behavior consistent with the cargo cache change.

In @.github/workflows/release.yml:
- Around line 297-311: The "Cache oxide build" step's cache key uses ${{
matrix.target }} which doesn't exist in this job's matrix; update the step so
the key references the actual matrix variable used for the oxide build (or move
this step into the job that defines the matrix), e.g. replace ${{ matrix.target
}} with the correct matrix identifier (such as the matrix entry that holds the
build target name) or remove it and rely on runner.os+hashFiles to avoid a
non-existent variable; target the key expression in the "Cache oxide build" step
(the key: ${{ runner.os }}-${{ matrix.target }}-oxide-${{
hashFiles('./crates/**/*') }}) when making the change.