CI: zizmor flags unpinned GitHub Actions in check-renovate.yaml / release-publish.yaml

Nobody has claimed this yet.

🤖 [BEEP BOOP, A BOT WROTE THIS COMMENT - Claude Sonnet 5, GitHub Copilot CLI]

The repository's `zizmor` code-scanning check flags several `unpinned-uses` findings (actions referenced by tag instead of commit hash) in two starbase-owned workflow files:

- `.github/workflows/check-renovate.yaml` (`actions/checkout`, `actions/setup-node`, `mxschmitt/action-tmate`)
- `.github/workflows/release-publish.yaml` (`softprops/action-gh-release`, plus a `superfluous-actions` note that `gh release` could replace it)

These findings are **pre-existing on `main`** (confirmed by running `zizmor` locally against `origin/main` before any starbase-merge changes — the same actions were already unpinned, just at older version tags). They surfaced as new PR annotations in [#402](https://github.com/canonical/imagecraft/pull/402) only because that PR bumped the action versions (e.g. `actions/checkout@v6` → `@v7`), which caused `zizmor`'s "new alerts in changed code" heuristic to flag the already-unpinned lines.

Since both files are owned by `starbase` (Canonical's shared craft-tool scaffolding) rather than `imagecraft` itself, the long-term fix (hash-pinning these actions, or excluding/allow-listing them) likely belongs upstream in `canonical/starbase` so all consuming repos benefit. Tracking here so it isn't lost, and so future `update-starbase` merge PRs aren't blocked/confused by it.

Start by running zizmor against .github/workflows/check-renovate.yaml and .github/workflows/release-publish.yaml, then compare the findings with the corresponding starbase-owned workflows. Done means the unpinned-action findings are resolved through the appropriate starbase change or an agreed exclusion/allow-list, with future update-starbase PRs no longer producing these alerts.

Written by the indexing model from the issue text.