fix(ci): drop Test PyPI entirely rather than fix its trusted publisher

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 to route a release candidate to a separate staging index to hold
it safely. Test PyPI existed here only as that safety net.

publish-to-pypi now runs unconditionally instead of skipping for a
release candidate, which also makes this consistent with what npm and
Maven Central already do. publish-dev-to-testpypi.yml is deleted --
it's been failing on every push to main since the 2026-08-16 migration
anyway (see reqstool/.github#92), and there's nowhere left for it to
publish to.

Needs reqstool/.github#92 merged first.

Signed-off-by: Jimisola Laursen <jimisola@jimisola.com>

Author: jimisola

.github/workflows/publish-dev-to-testpypi.yml

@@ -95,26 +95,13 @@ jobs:
       version: ${{ needs.prepare.outputs.version }}
       artifact: dist-tagged
 
-  publish-to-testpypi:
-    needs: [prepare, assets]
-    runs-on: ubuntu-latest
-    environment:
-      name: test
-      url: https://test.pypi.org
-    permissions:
-      id-token: write
-    steps:
-      - uses: reqstool/.github/.github/actions/publish-to-pypi@main
-        with:
-          target: testpypi
-          artifact: dist-tagged
-
   # PyPI is the only step here that cannot be undone: a version can be yanked but
-  # never replaced. A release candidate stops at Test PyPI -- pip needs --pre to
-  # see a prerelease anyway.
+  # never replaced. Publishes release candidates too, with their pre-release
+  # identifier -- pip ignores them without --pre, so there is nothing unsafe
+  # about it landing on the real index; there is no separate staging index to
+  # route them to instead. Matches npm and Maven Central's existing behavior.
   publish-to-pypi:
-    needs: [prepare, publish-to-testpypi]
-    if: ${{ needs.prepare.outputs.prerelease != 'true' }}
+    needs: [prepare, assets]
     runs-on: ubuntu-latest
     environment:
       name: stable
@@ -124,24 +111,19 @@ jobs:
     steps:
       - uses: reqstool/.github/.github/actions/publish-to-pypi@main
         with:
-          target: pypi
           artifact: dist-tagged
 
   # Last, deliberately. Everything above can fail, and until this runs nothing
   # resolving "the latest release" can see what was built -- the release is still
   # a prerelease. Promotion itself is one API call against a release that already
   # has its artifacts.
   #
-  # The guard is `no job failed`, not the default `every job succeeded`: a release
-  # candidate deliberately skips the publish jobs that a real release runs, and a
-  # skipped dependency would otherwise cascade and skip this too -- leaving the
-  # candidate unpromoted, which is right, and every *real* release unpromoted the
-  # moment any optional job is skipped, which is not.
-  #
-  # `!inputs.dry-run` has to be spelled out for the same reason: on a dry run
-  # every job above is skipped, and "nothing failed" would otherwise be true.
+  # The guard is `no job failed`, not the default `every job succeeded`: on a dry
+  # run every job above is skipped, which would make plain success() false too --
+  # `!inputs.dry-run` is what actually gates this job then, and `no job failed`
+  # is what confirms nothing above it errored on a real run.
   promote:
-    needs: [prepare, assets, publish-to-testpypi, publish-to-pypi]
+    needs: [prepare, assets, publish-to-pypi]
     if: ${{ !inputs.dry-run && !cancelled() && !contains(needs.*.result, 'failure') && !contains(needs.*.result, 'cancelled') }}
     uses: reqstool/.github/.github/workflows/common-release-promote.yml@main
     permissions: