chore(release): purge ./publish script + document GH-Action release flow (#457)

PyPI releases land via `.github/workflows/release-auto.yml` and PyPI
trusted publishing (OIDC) — the legacy `./publish` shell wrapper and
the local CLI flow inside `ci/publish.py` (`main()`, `argparse`,
`trigger_and_wait`, `download_artifacts`, `upload_wheels`,
`check_pypi_version`, `verify_published`, ...) are no longer used by
anything but were still being documented as the release procedure.

Worse: they were misleading. The intuitive flow they implied —
"bump version, tag v<version>, run ./publish" — *breaks* the
GH-Action gate. The action's `prepare` step refuses to build when
the tag already exists, so a manually-pushed tag turns every
subsequent push into a silently-skipped no-op release. (See
release-auto.yml:91 — `should_build` requires `tag_exists != "true"`.)

Changes:

- Delete `./publish` (the bash entry point).
- Rewrite `ci/publish.py` down to the library surface
  `release-auto.yml`'s `build-pypi` step imports: `DIST_DIR`,
  `WHEEL_DIR`, `PYTHON_SHIMS_DIR`, `ARTIFACT_MAP`, `PLATFORMS`,
  `EXTENSION_NAMES`, `log`, `record_hash`, `read_project_meta`,
  `build_wheel`, `build_all_wheels`. 462 lines of dead local-CLI
  code removed; the wheel-assembly behaviour the workflow depends
  on is byte-equivalent (sanity-checked via `python -c "import
  publish; ..."`).
- Add `docs/RELEASING.md` with the actual end-to-end procedure:
  bump both files, push (no tag), let the action do everything;
  plus failure-mode recovery (delete a manually-pushed tag and
  re-run the workflow via `workflow_dispatch`; that's the bug that
  caught me on the 2.2.19 cut today).
- Update every doc/comment that pointed at the old flow: CLAUDE.md,
  docs/DEVELOPMENT.md (×2), python/README.md, ci/bin_launcher.py,
  setup.py.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: zackees

CLAUDE.md

@@ -46,16 +46,20 @@ soldr cargo run -p fbuild-config --bin enrich_boards  # enrich from local Platfo
 
 ## Distribution
 
-Native binaries are built via GitHub Actions and downloaded locally for packaging. PyPI is the distribution channel — no Python in the runtime hot path.
+Releases ship via the **Autonomous Release** GitHub Action (`.github/workflows/release-auto.yml`). PyPI is the distribution channel; per-platform native binaries are built, assembled into wheels, and uploaded via PyPI trusted publishing — there is no local publish script.
 
-```bash
-# Build all platforms (triggers GH Actions, waits, downloads to dist/)
-uv run python ci/build_dist.py --ref main
+To cut a release:
 
-# Publish to PyPI
-./publish
+```bash
+# 1. Bump version in both files (must match)
+#    Cargo.toml  -> [workspace.package] version
+#    pyproject.toml -> [project] version
+# 2. Push the bump commit to main (do NOT push a tag manually —
+#    the action creates one only after the build + upload succeed)
 ```
 
+See [docs/RELEASING.md](docs/RELEASING.md) for the full flow, gating logic, and re-run instructions when a release stalls.
+
 Optional wrapper-mode only; do not use for standard soldr builds:
 
 ```bash

ci/bin_launcher.py

@@ -8,9 +8,10 @@
 process — so process semantics (PID, signal handling, stdio inheritance,
 exit code) match what bare-cargo `target/release/fbuild` would give.
 
-The release wheels published to PyPI by `ci/publish.py` follow the same
-layout: pre-built native binary at `ci/bin/fbuild[.exe]`, this launcher as
-the entry point.
+The release wheels published to PyPI by the Autonomous Release GitHub
+Action (`.github/workflows/release-auto.yml`, which calls into
+`ci/publish.py`) follow the same layout: pre-built native binary at
+`ci/bin/fbuild[.exe]`, this launcher as the entry point.
 """
 
 from __future__ import annotations