Add reusable Release and Promote workflows

[ezekiel-alexrod]

What

Adds two reusable workflows that mutualize the release flow currently
copy-pasted across 9 repos (go-errors, crl-operator, disk-management-agent,
file-reflector, metalk8s-registry-node-agent, metalk8s-registry-operator,
prometheus-postgres-adapter, static-oci-registry, raidmgmt):

• release.yaml (workflow_call): computes the next semver
  (alpha/beta/GA × patch/minor/major) off the last GA tag reachable
  from the current branch and pushes an annotated v* tag with the GitHub App
  token. Exposes a tag output and a dry-run input.
• promote.yaml (workflow_call): creates a GitHub Release from a pushed
  v* tag, marked pre-release when the tag contains a hyphen.

Plus: docs/release-promote.md (library and service caller examples), a
release-dry-run job in tests.yaml exercising the version computation on
every PR, and a CLAUDE.md table update.

Why

The prepare-version/create-release pair exists in 9 copies across the org,
so every fix means 9 PRs. This factors it into a single maintained
implementation, adapted from scality/raidmgmt#77 (itself derived from
go-errors/nodeip-discovery).

Compared to the legacy copies, this version:

• computes the base tag with git tag --merged HEAD --sort=version:refname
  instead of --sort=taggerdate: an out-of-order hotfix tag (e.g. v1.0.1
  tagged after v2.0.0) can never be picked as the base version, and the
  computation stays correct if per-minor release branches (dev/X.Y) are
  introduced;
• guards the GA-tag grep (|| true) so the 0.0.0 fallback fires on a repo
  with no GA tag yet;
• declares explicit token permissions (contents: read in release,
  contents: write in promote);
• validates version-type/version-scope at runtime (workflow_call cannot
  express type: choice, so the choices stay in the callers'
  workflow_dispatch);
• adds dry-run (compute and validate without pushing), which makes the
  workflow testable in PR CI;
• drops the git fsck/git gc calls, pointless on a fresh CI clone.

Design notes

• The release title is the tag alone (e.g. v1.2.3): the repository already
  provides context in the GitHub UI, so the title is not prefixed with the repo
  name by default. product-name is an optional input that prefixes both the
  release title and the tag annotation (e.g. product-name: MetalK8s →
  MetalK8s v1.2.3), useful for monorepos or when the product name differs
  from the repository name.
• The tag must be pushed with an App token: tags pushed with the default
  GITHUB_TOKEN do not trigger on: push: tags, so Promote would never fire.
  actions-app-id is an explicit input; ACTIONS_APP_PRIVATE_KEY is passed via
  secrets: inherit.
• Promote only creates the GitHub Release. A service chains its image build in
  the caller (needs: build) so a broken build still blocks the release; a pure
  library calls Promote directly: the tag is the artifact.
• Quality gates (tests before tagging) stay in the callers: a library gates on
  go test, a service may gate differently.
• Action pins follow this repo's convention (major version tags), not the SHA
  pins used in product repos.

Migration plan (follow-up PRs, not in this PR)

1. Tag v2.9.0.
2. 9 mechanical PRs replacing the local copies (roughly -80/+15 lines each). The
   taggerdate fix lands with the migration, no separate backport needed.
3. Later, optional: converge the 5 platform-* repos (currently
   release-published → test after publication) onto the same pair.