OpenSSF Scorecard hardening (token-permissions, signed-releases, vuln triage, image digests, CII badge)

## OpenSSF Scorecard hardening — remaining items

Tracking the [Scorecard](https://scorecard.dev/viewer/?uri=github.com/Azure/kars) findings. Two items are **already addressed** in flight:

- ✅ **Vulnerabilities** — `RUSTSEC-2026-0185` (quinn-proto) fixed in #409.
- ✅ **Pinned-Dependencies (GitHub Actions)** — pinned the 12 remaining `@v4` GitHub-owned actions by SHA (#410).

### Remaining (prioritized)

**1. Token-Permissions (high)** — move top-level `contents/packages/actions/security-events: write` to the specific jobs that need them; set top-level to `read`. Affected: `release.yml`, `codeql.yml`, `blocklist-refresh.yml`, `image-cache-publish.yml`, `release-internal.yml`, `release-public-interim.yml`. ⚠️ Touches release/signing jobs — change per-job + verify a full release run before merging.

**2. Signed-Releases (high)** — GitHub Release **tarball assets** aren't signed (container images already are: cosign keyless + SBOM + SLSA provenance). Add a cosign signature / SLSA provenance step for `kars-cli-*.tgz` + the binary tarballs in the release workflow.

**3. Vulnerabilities (high)** — triage the remaining OSV findings: `RUSTSEC-2024-0370` (proc-macro-error unmaintained), `RUSTSEC-2026-0173`, `RUSTSEC-2023-0071` (rsa Marvin — no fix), `RUSTSEC-2025-0134`, and `GHSA-{4v58-8p28-2rq3,8m7c-8m39-rv4x,h67p-54hq-rp68,fx2h-pf6j-xcff,v6wh-96g9-6wx3,4x5r-pxfx-6jf8,848j-6mx2-7j84}`. Bump where fixes exist; document accepted/unfixable (unmaintained transitive, no-patch advisories) in `deny.toml` / an osv-scanner ignore with rationale.

**4. Pinned-Dependencies — container images & build commands (medium)** — 18/26 container base images use mutable tags (`mcr.microsoft.com/azurelinux/...:3.0`). Pin by digest (Scorecard provides digests) — best paired with Renovate/Dependabot digest auto-updates so they don't rot. Also: `pip`/`npm`/`go` install commands not hash-pinned (largely covered by `Cargo.lock` / `package-lock.json` / vendored wheels, which Scorecard doesn't credit) — decide hash-pin vs. document.

**5. Binary-Artifacts (high)** — `vendor/sandbox-wheels/*.whl` (~130 wheels) are **intentional**: they make `kars-sandbox-base` build hermetically/offline with no PyPI dependency, and are tracked via LFS. This is a deliberate supply-chain tradeoff (vendored + checksummed > live PyPI pull). Document the rationale; evaluate whether Scorecard's allowlist/exemption mechanism applies.

**6. CII-Best-Practices (low)** — apply for the [OpenSSF Best Practices badge](https://www.bestpractices.dev/).

### Notes
- Many Scorecard checks penalize deliberate, security-positive choices here (vendored wheels; SHA-pinned-but-via-comment). Each item should be a small, independently-verifiable PR — especially Token-Permissions, which must not break the release/signing jobs.

Start by reading the six affected workflows: release.yml, codeql.yml, blocklist-refresh.yml, image-cache-publish.yml, release-internal.yml, and release-public-interim.yml. Review deny.toml and the vendored wheels before choosing one independently verifiable Scorecard item. Done means the selected hardening change is applied, its workflow or release behavior is verified, and any accepted exceptions have documented rationale.

Written by the indexing model from the issue text.