fix(ci): the composite consumers execute runs setup-uv v9, not v8.3.2

[hseshadr]

The defect

#12 bumped astral-sh/setup-uv 8.3.2 → 9.0.0 but touched only .github/workflows/ci.yml — this repo's own self-test. The file consumers actually execute, .github/actions/setup-python-uv/action.yml:54, stayed on v8.3.2. The bump reached nobody downstream.

The split was already visible in the field: edge-proc and edgeproc-core run v9.0.0 directly in their own ci.yml while calling this composite on their publish path. v9 on the test path, v8.3.2 on the publish path, same repo.

The change

One pin, plus the adjacent comment whose version range the bump made stale.

-    # setup-uv publishes no floating major tag (only v8.x.y). The full commit SHA
-    # and readable release comment keep execution immutable and updates reviewable.
-    - uses: astral-sh/setup-uv@11f9893b081a58869d3b5fccaea48c9e9e46f990 # v8.3.2
+    # setup-uv publishes no floating major tag (only vX.Y.Z — `v9` 404s upstream).
+    # The full commit SHA and readable release comment keep execution immutable and
+    # updates reviewable. The comment must name the exact version, never `# v9`:
+    # zizmor's ref-version-mismatch resolves it upstream and a float turns red on
+    # the next patch release.
+    - uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0

The SHA, verified independently

gh api repos/astral-sh/setup-uv/tags:

Tag	SHA
v9.0.0	c771a70e6277c0a99b617c7a806ffedaca235ff9 ← incoming
v8.3.2	11f9893b081a58869d3b5fccaea48c9e9e46f990 ← outgoing

gh api .../git/ref/tags/v9.0.0 resolves to the same commit. It is also the SHA #12 used and the one both consumers already run.

The comment names the exact version

#13 just removed five floating-major comments. zizmor's ref-version-mismatch resolves the version comment against upstream, so # v9 turns main red the moment astral-sh cuts a patch. No floating major tag exists upstream anyway — v9 and v8 both 404 on the refs API.

Claim touched

Consumers of this composite run a pinned, immutable, auditable setup-uv.

True about immutability, false about which version. The pin CI audited and the pin consumers executed lived in different files, and only one of them got bumped. This PR makes the audited pin and the executed pin the same pin.

Evidence

Check	Result
GH_TOKEN=… uvx zizmor@1.26.1 .	exit 0 — "No findings to report" (1 ignored, 10 suppressed)
actionlint	clean
shellcheck -x + bash -n	clean
tests/security-policy.sh	exit 0 — "Security policy checks passed."
tests/lint-examples.sh	exit 0 — 173 refs resolved, 0 MISSING, 0 UNVERIFIABLE across 7 consumer repos

Anything else still on v8.3.2

Nothing executable. grep -rn 11f9893b081a58869d3b5fccaea48c9e9e46f990 returns exactly one hit on main, and this PR is it. The remainder is prose and left alone deliberately — no gate reads it:

• README.md:422 — pin-convention table says # v8.3.2
• README.md:197 — sample snippet shows @v8.1.0
• CHANGELOG.md:273,401 — historical entries, correct as history

Not in this PR

.github/workflows/python-gate.yml:82 still pins this composite at @2a575cd… # ci-v3.0.0. Re-pointing it needs this PR's merge SHA, which does not exist yet. It is the deliberate next step, not an oversight.

🤖 Generated with Claude Code

https://claude.ai/code/session_015o7tjWLFZvzRv4KyNfDukx

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.