feat: auto-cut patch releases when a CLI version is added

[TerryHowe]

What

Adds a workflow that automatically cuts a patch release when a new ORAS
CLI version lands in src/lib/data/releases.json on main, plus a
RELEASING.md documenting the release process.

Follows on from the manual v2.0.1 release, which shipped ORAS CLI 1.3.2 and
1.3.3 support. That release was cut entirely by hand; this automates the common
case so a new CLI version releases itself.

How it works

.github/workflows/auto-release.yml triggers on push to main filtered to
src/lib/data/releases.json (e.g. after the Update releases.json PR merges):

1. Detect — diffs releases.json against HEAD^ and extracts newly added
   version keys. If none were added (dependency bumps, formatting, checksum
   edits), the job ends without releasing.
2. Version — finds the latest vX.Y.Z tag and patch-bumps it
   (v2.0.1 → v2.0.2). Idempotent: skips if the target tag already exists.
3. Release — gh release create off the pushed commit with a Highlights
   body naming the added CLI version(s).
4. Move tags — force-moves vX and vX.Y to the release commit,
   in the same job.

Why the tag move is in-job

A release created with the default GITHUB_TOKEN does not emit a
release: published event (GitHub suppresses it to prevent workflow
recursion), so the existing update-version.yml would never fire. Doing the
major/minor tag move directly in this job avoids needing a PAT. The workflow
only pushes tag refs, so it cannot self-trigger.

Scope / guardrails

• Patch-only. Minor and major releases (breaking action changes, e.g. the
  Node runtime migration in v2.0.0) stay manual — see RELEASING.md.
• concurrency: auto-release serializes releases.
• workflow_dispatch is included for manual testing.
• Only elevated permission is contents: write.

Note for reviewers

The github-actions bot must be permitted to force-push vX / vX.Y under
any tag protection ruleset. update-version.yml already does this today, so
the same permissions apply.

🤖 Generated with Claude Code