ci: SHA-pin actions, scope permissions, add Dependabot

[BCook98]

Problem

The kit CI workflows are a supply-chain surface: .github/workflows/* were not
all consistently hardened. This PR makes the hardening complete and reviewable:

• Action references should be pinned to full commit SHAs (mutable tags can be
  re-pointed to malicious commits).
• Each workflow should declare a least-privilege top-level permissions: block.
• Toolchain installs should be pinned where feasible.
• Dependabot should keep the pins current.

Files: .github/workflows/ci.yml, .github/workflows/govulncheck.yml,
.github/workflows/release.yml, .github/workflows/release-cli.yml,
.github/dependabot.yml.

Fix

• SHA-pin every action in all four workflows, each with a trailing
  # vX.Y.Z comment. The pinned SHA for each semver tag was resolved via
  gh api repos/<owner>/<action>/commits/<tag> and re-verified in this PR:
  • actions/checkout v4.3.1 -> 34e1148…
  • actions/setup-go v5.6.0 -> 40f1582…
  • actions/setup-node v4.4.0 -> 49933ea…
  • changesets/action v1.9.0 -> a45c4d5…
  • goreleaser/goreleaser-action v6.4.0 -> e435ccd…
  • acifani/setup-tinygo v2.0.1 -> db56321…
  • dtolnay/rust-toolchain @stable head -> 29eef33… (moving stable tag,
    pinned to its current head SHA — there is no semver tag for it).
• Least-privilege permissions:: ci.yml and govulncheck.yml get a
  top-level permissions: { contents: read }. release.yml
  (contents: write + pull-requests: write for the Version Packages PR /
  tag push) and release-cli.yml (contents: read; its privileged steps use
  the KIT_RELEASE_TOKEN PAT, not GITHUB_TOKEN) keep their existing scoped
  blocks — no job needs the default token widened.
• Toolchain pinning: TinyGo stays pinned at 0.41.1 via setup-tinygo.
  binaryen's apt-get install is intentionally left at the runner's apt
  candidate (documented inline in ci.yml): pinning a literal binaryen=<ver>
  hard-fails the install whenever ubuntu-latest's candidate moves, and TinyGo
  — the toolchain that actually shapes the wasm — is the pinned input that
  matters. This is the one install that could not be safely version-pinned.
• Dependabot: .github/dependabot.yml covers gomod and github-actions
  (weekly), so the SHA pins (and their # vX.Y.Z comments) are bumped
  automatically as new releases land.

No CI logic changed — only pins, permissions, and the new Dependabot config.

Verification

• actionlint (v installed in CI image) — clean on all four workflows.
• All six semver-tagged SHAs re-resolved via gh api …/commits/<tag> and
  confirmed byte-identical to the committed pins.
• Diff confirmed to touch only .github/** (workflows + dependabot).

Could not run the workflows end-to-end here (they require GitHub-hosted runners

• release secrets); static validation via actionlint + API SHA verification is
  the meaningful gate for a pins/permissions-only change.

Reviewers, focus on

• The permissions: scoping decisions (esp. that release-cli.yml is fine at
  contents: read because it authenticates with the KIT_RELEASE_TOKEN PAT).
• The deliberate non-pin of binaryen and its inline rationale.
• The dtolnay/rust-toolchain # stable pin — it is a moving tag head, so
  Dependabot's github-actions ecosystem will track it.

🤖 Generated with Claude Code