fix(ci): move PyPI publish out of a reusable workflow

[jimisola]

Description

PyPI does not accept a reusable workflow as a trusted publisher, full stop —
pypi/warehouse#11096, unresolved. The
workaround, confirmed working elsewhere
via OpenAstronomy's docs:
the job that calls pypa/gh-action-pypi-publish must be defined directly in the caller's
own workflow file. A composite action is fine — the OIDC claim is about which workflow file
the job runs in, not what its steps reference — but workflow_call is not.

python-publish-to-pypi.yml was exactly the shape PyPI rejects. Confirmed two ways today:

1. Four real release runs — reqstool-client, reqstool-python-decorators,
   reqstool-python-hatch-plugin, reqstool-python-poetry-plugin — all failed identically
   at the publish step, after tag/build/assets all succeeded, with
   invalid-publisher: valid token, but no corresponding publisher. This is a different,
   deeper problem than the workflow-filename/environment staleness fixed for npm's trusted
   publisher — no config value on pypi.org could have fixed it.
2. publish-dev-to-testpypi.yml — a separate workflow publishing a dev build to Test PyPI
   on every push to main — has been failing on every run since the 2026-08-16
   migration, across all four repos, for a week, unnoticed.

What changes

• New: .github/actions/publish-to-pypi, a composite action wrapping the
  download-artifact → (dry-run twine check | pypa/gh-action-pypi-publish) steps
  python-publish-to-pypi.yml had.
• Deleted: python-publish-to-pypi.yml and its test stub, rather than kept around
  deprecated — a known-broken-for-purpose reusable workflow left in place is exactly what
  invites someone to wire it up again.
• Test PyPI is gone, not carried forward. PyPI accepts a pre-release version identifier
  (0.3.0rc1) on the real index directly, and pip ignores it without --pre — there was
  never a need for a separate staging index to hold a candidate safely, so the action has no
  target input at all, just PyPI.
• RELEASING.md: updated throughout — the staging-publish step is gone, the pipeline
  diagram points at the composite action, the test environment is now unused (left
  declared rather than removed, in case a future index needs it), the trusted-publishing
  warnings drop the test.pypi.org references, and the release-candidate section documents
  PyPI's new behavior (publishes straight to the real index, like npm and Maven Central)
  next to the existing VS Code exception.

What this loses

The old workflow derived environment: stable from target automatically for the real
index. A composite action can't set the caller's environment: — that's a job-level
attribute only the workflow file itself can declare. Every caller now sets it explicitly.

Companion PRs

Every PyPI-publishing repo's release.yml needs to stop calling python-publish-to-pypi.yml
and switch to this action instead, and drop its own Test PyPI jobs:
client#444,
decorators#91,
hatch-plugin#102,
poetry-plugin#139.

Merge order: this one first — the companions reference
reqstool/.github/.github/actions/publish-to-pypi@main, which doesn't exist until this
merges.

Checklist

• I have reviewed and followed the contributing guidelines.
• I have run a local build and made sure all tests pass.
• I have signed off the Developer Certificate of Origin (git commit -s).
• I have read the Code of Conduct and agree to abide by it.

Test plan

tests/actions/run-tests.sh — 40/40 passing locally. shellcheck, yamllint, and zizmor
all clean locally (zizmor caught a real template-injection finding mid-review — target
validation was interpolating ${{ inputs.target }} directly into a run: string instead of
going through env:; fixed, and now moot since the target input is gone entirely).
tests/python/publish-to-pypi.yml's actionlint coverage is gone with the file it tested;
the composite action has no workflow_call surface for actionlint to check the same way, so
the companion PRs' real dispatches are the actual test.