ci: harden release pipeline against supply-chain

[KyleJune]

Summary

Hardens the release pipeline against the npm / GitHub Actions supply-chain attack
class (udibo/udibo#36). The publish job is the only one with id-token: write, so
the goal is that the only code running there is pinned and integrity-checked.

Changes

• Run semantic-release through Deno, not npx.
  deno run -A npm:semantic-release resolves semantic-release and all plugins
  from deno.lock under minimumDependencyAge, with npm lifecycle scripts
  disabled by default. npx fetched them fresh and unpinned on every release
  while id-token: write was active — the exact exposure the postmortem
  describes. actions/setup-node is removed (no more node/npm in CI).
• Versions pinned in deno.json: semantic-release ^24 (v25's engines
  >=24.10 reject Deno's emulated Node 24.2.0); @sebbo2002/semantic-release-jsr
  held at 3.2.1 (4.0.0 is EPLUGINSCONF-broken); plugins pinned via the lockfile.
• Pin every GitHub Action to a commit SHA, including
  amannn/action-semantic-pull-request which runs in the privileged
  pull_request_target title check.
• Top-level permissions: contents: read so the non-release jobs drop from
  the default write token; the release job keeps its explicit elevated block.
• cache: false on the publish job's setup-deno — the OIDC job restores no
  shared cache.
• deno ci instead of deno install; documented why pr-title.yml's
  pull_request_target is safe (no checkout, no cache, read-only).

Trade-off

Release tooling now lives in the workspace deno.json, so deno ci / deno install pulls it for all contributors (cached in CI). Kept simple and
Deno-native per the issue; a dev/prod split can follow if install weight matters.

Testing

Verified locally on Deno 2.8.2: deno run -A npm:semantic-release --dry-run loads
all six plugins and correctly no-ops off main; deno ci and deno task check
pass.