ci: adopt shared reusable release-tag workflow

[supertokens-agent-runner]

Problem

.github/workflows/pipeline-release-tag.yml was a per-repo copy of the release
pipeline. PLAN-001 consolidated the three SDK copies (node/python/golang) into a
single workflow_call workflow in supertokens/actions
(.github/workflows/release-tag.yml@main, added in supertokens/actions#13,
PLAN-001 C2). This unit ports supertokens-python onto that shared workflow so the
release skeleton stops drifting across repos.

Fix

Replace the file with a thin caller of the shared reusable workflow,
parameterized sdk_name: python with secrets: inherit. The shared five-job
skeleton (setup → register-version → mark-as-success → release →
merge, including the post-release dev sync) now lives once in the reusable
workflow.

The two python ecosystem follow-ups stay in the caller and are rewired to
consume the reusable workflow's outputs via needs.release-pipeline.outputs.*:

• publish-docs — uses releaseTag, isLatest, version, and the derived
  version folder ${{ needs.release-pipeline.outputs.versionXy }}.X. The
  reusable workflow exposes version/versionXy rather than python's old
  versionFolder/artifactName, so those are derived inline
  (python-docs-<version>, <versionXy>.X). Its app-token still requests both
  this repo and supertokens-backend-website.
• publish (PyPI/twine) — checks out releaseTag, keeps its
  environment: publish gate; unchanged otherwise.

changelog_add_paths is set to .changes/ CHANGELOG.md setup.py supertokens_python/constants.py so the reusable workflow's release changelog
commit stages every .changie.yaml replacement target (the default
.changes/ CHANGELOG.md would miss python's two version files).

Version-hook contract: the reusable setup job sources
hooks/populate-hook-constants.sh and reads constantsVersion /
constantsVersionXy — which python already exported, so no shim was needed for
the contract itself. The one relocation: the previous copy's inline "Constants
version and setup version mismatch" guard (which the reusable setup does not
carry) moved into populate-hook-constants.sh, per the shared contract's note
that repo-specific setup checks belong in the hook and exit non-zero. That same
invariant is still independently enforced by hooks/check-version.sh
(pre-commit) and .github/workflows/check-docs.yml (on version-branch push).

Behaviour vs. the previous flow

Identical except for differences inherited from the shared workflow:

1. Documented ordering change: the git tag is pushed before the API
   release: true PATCH (the tag is the release; the API mark follows reality).
2. Minor cosmetic: the GitHub Release title is now
   supertokens-python <version> (repo name) instead of Python SDK <version>.
3. Internal: mark-as-success relies on check-tests-passed's setup-python: true instead of the old explicit setup-python + pip install httpx step —
   same effect.

register-version and the post-release dev sync were already present in
python's copy (python was a baseline for the shared workflow), so they are
unchanged in behaviour — only their home moved.

Tests added / run

None. There is no unit-testable surface here — these are release-time GitHub
Actions paths.

• bash -n hooks/populate-hook-constants.sh — OK.
• Sourced the hook in a checkout: exports constantsVersion/constantsVersionXy
  and the mismatch guard passes (constants.py and setup.py both 0.31.3).
• YAML parse of the caller — OK.
• pre-commit run over the changed files: check-version, check-branch,
  trim trailing whitespace, fix end of files, don't commit to branch all
  Passed; ruff/ruff-format/check python ast skipped (no .py changed).

Not verified

• The release / dev-sync paths cannot be exercised by CI on this PR. They run
  only when a release/vX.Y.Z PR merges into a version branch, or on manual
  workflow_dispatch. First real validation is the next python release — treat
  it as supervised.
• Presence of the secrets/vars the reusable workflow requires for this repo
  (RELEASE_APP_ID var, RELEASE_APP_PRIVATE_KEY, SUPERTOKENS_API_KEY,
  SUPERTOKENS_RELEASE_API_KEY, plus the caller's TWINE_USERNAME/
  TWINE_PASSWORD). The C0 unit (ci: mint App installation tokens in release workflows (retire ALL_REPO_PAT) #646) already wired
  RELEASE_APP_ID/RELEASE_APP_PRIVATE_KEY into the old pipeline, so those
  should be in place; the reviewer should confirm the twine creds.
• No recovery / re-run logic (by design — the reusable release job documents
  why: a pushed tag is immutable server-side and cached forever on the package
  index; the fix for a mid-release failure is a new patch version, never a
  retag).

Cross-SDK note

supertokens-node is the reference implementation and adopted the same shared
workflow in supertokens/supertokens-node#1058 (PLAN-001 C3); golang's adoption is
its own PLAN-001 unit. The reusable workflow was ported from golang (the cleanest
copy) and parameterized by sdk_name; python already emitted
constantsVersion/constantsVersionXy and already had register-version + the
post-release dev sync, so python's diff here is essentially caller-ification plus
the tag-before-API-mark ordering change and the mismatch-check relocation.

Reviewer note (PLAN-001)

PLAN-001 flags C-phase release-tag adoptions as high-risk / supervised — not
fast-merge. Opened as draft for that reason: the mechanical change is here,
but a human should confirm the secret/var wiring and sign off before the next
release exercises it.

Part of PLAN-001

Fixes #645

[supertokens-agent-runner]

CI triage:

• Green: lint / Lint PR Title, lint / Require Changelog Fragment, Check linting and formatting (3.8–3.13), define-versions, skip-check. The changie fragment satisfies the changelog gate and no .py files changed, so ruff/pyright pass on the unchanged tree.
• test-gate (fail) — pre-existing label gate, not caused by this change. The failing step is Evaluate test requirement; test-gate reds until the human test-run requirement (label) is satisfied. This diff only touches .github/workflows/pipeline-release-tag.yml, hooks/populate-hook-constants.sh, and a changie fragment — none of which feed that step. The same gate reds on other open PRs (e.g. fix: use correct base path for OAuth frontend redirects #639), confirming it is upstream of this change.
• The release/publish paths in the changed workflow are not exercised by this PR — they trigger only on a release/vX.Y.Z merge into a version branch or manual workflow_dispatch. First real validation is the next python release (supervised).