docs(release): add hybrid SVN-dist + ATR-vote backend to the release skills

[potiuk]

Why

While ATR is in alpha we don't yet trust it to host or publish releases,
but its automated checks and vote administration are useful now. This
codifies that RM decision as a hybrid backend: SVN hosts + promotes the
artefacts (ratified, trusted); ATR runs the Compose checks and drives the
dev@ [VOTE]. Previously the backend was a single svnpubsub-or-atr
switch — this decouples "where artefacts live / how they're promoted" from
"who administers the vote."

What

• release-management-config.md (magpie + template) — new
  release_vote_backend (manual | atr), independent of
  release_dist_backend. Documents the hybrid (svnpubsub + atr) and
  that ATR's Finish/publish is not used until the dist backend itself
  becomes atr. Adds atr_platform_url to the template. Magpie is set to
  release_dist_backend = svnpubsub, release_vote_backend = atr.
• release-rc-cut — when release_vote_backend = atr, emits an
  atr upload block after the SVN staging so ATR has a candidate to check
  and vote on. Never emits an ATR finish/publish while dist = svnpubsub.
• release-vote-draft — emits atr vote start -m … --subject … --no-auto-publish <project> <version> (RM runs it; ATR sends + tabulates)
  instead of a paste-ready email; the body still points voters at the SVN
  dist/dev download URL.
• release-vote-tally — reads the tally from atr vote tabulate, still
  classified against the PMC roster.
• release-promote — promotion follows release_dist_backend
  (svn mv), never ATR Finish, regardless of the vote backend.
• atr-release-runbook.md — a Hybrid-mode callout describing the split.

CLI accuracy

Matched to the installed atr client (0.20260709.x): the vote targets the
latest uploaded revision by default (optional --revision), so the docs no
longer depend on a revisions lookup, and note that verb names may shift
between ATR releases.