docs: correct the release workflow description in the README

[MohammedAlkindi]

The "Release Workflow" section describes a release flow that no longer exists.

It documents a second workflow input, claude_code_version, and a release-branch-plus-PR path ending in "Review and merge the release PR". Neither is real:

• .github/workflows/publish.yml declares exactly one workflow_dispatch input, version. claude_code_version appears nowhere in the repo except the README line this PR removes.
• .github/workflows/build-and-publish.yml has a "Push to main" step running git push origin main, then tags with git tag -a "v$VERSION" and calls gh release create. There is no gh pr create, no checkout -b, and no release branch under .github/ at all.
• RELEASING.md already documents the real flow ("pushes to main, and creates a git tag + GitHub Release", and DEPLOY_KEY as "SSH key for direct pushes to main"), so the README currently contradicts it.

The section also claimed the two versions are tracked separately "allowing you to release a new package version with an updated CLI without code changes". The bundled CLI version is pinned in src/claude_agent_sdk/_cli_version.py and read by scripts/build_wheel.py at build time, so updating it is a code change.

How it drifted

The section was added in #283 (2025-11-18) and was accurate that day — that PR really did add a claude_code_version input, a git checkout -b, and a gh pr create. It then decayed in two steps that both skipped the README:

• refactor: source CLI version from code in publish workflow #350 (2025-11-19) removed the claude_code_version input, touching only publish.yml.
• ci: simplify release flow and add RELEASING.md #539 (2026-01-30) removed the PR-based path outright — "always push directly to main (remove PR-based release path)", deleted create-release-tag.yml, and dropped pull-requests: write from the release workflows.

git log -L on these lines returns exactly one commit, #283, so the section has never been revised since it was written.

What this PR changes

Corrects the section to match the workflows: one input, direct push to main, tag + GitHub Release, and a note that the CLI version is pinned in code rather than passed in. It also adds the first link from the README to RELEASING.md, and fixes the opening sentence — publish.yml doesn't publish anything itself, it calls the reusable build-and-publish.yml.

I kept the corrections narrow and did not touch the "macOS, Linux, and Windows" bullet, though it's worth noting it undercounts: the matrix is five runners and build-and-publish.yml hard-fails unless all five platform tags are present.

Happy to go the other way instead — given that RELEASING.md covers all of this and the README copy has now drifted through two refactors, replacing this section with a short pointer to RELEASING.md may be the better fix. Say the word and I'll swap it.

One thing I noticed while verifying, unrelated to this PR

The last three auto-release.yml runs (2026-08-21, -22, -23) all concluded failure at the "Publish to PyPI (sdist first, then wheels)" step, with all five build-wheels jobs succeeding. The latest release is v0.2.143 from 2026-08-20, while main has since taken CLI bumps to 2.1.239, 2.1.240 and 2.1.241 with no release commit after them. Flagging in case it isn't already on your radar; I haven't filed anything separately.

---

AI assistance: I used Claude Code for this investigation. Verified myself against upstream/main rather than taken on trust: the single version input in publish.yml; the git push origin main / git tag -a "v$VERSION" / gh release create steps in build-and-publish.yml; that no gh pr create or checkout -b exists under .github/; that build_wheel.py reads the pinned __cli_version__ from _cli_version.py; the #283 → #350 → #539 provenance; and the auto-release.yml run conclusions and commit history cited above.