ci: keep beta release-please versions valid

[bokelley]

Summary

• switch release-please to its prerelease versioning strategy while the SDK is on the beta train
• add a post-release-please normalizer that rewrites pyproject.toml prereleases from SemVer to PEP 440
• cover alpha, beta, rc, stable, existing PEP 440, and non-project version fields with focused tests

Root Cause

Release-please was using default SemVer versioning, so a beta-line breaking commit generated 7.0.0-beta.1 from 6.1.0-beta.1. During this beta train we want the prerelease ordinal to advance instead. Separately, release-please writes raw SemVer prereleases like 6.1.0-beta.2 into pyproject.toml; Python packaging expects PEP 440, so the package version needs to be 6.1.0b2.

Validation

• PYTHONPATH=src pytest tests/test_normalize_pyproject_prerelease.py -q
• python3 -m json.tool release-please-config.json
• pre-commit hooks: black, ruff, mypy, yaml/json, whitespace, merge-conflict checks

Closes #830.

[aao-ipr-bot]

LGTM. Follow-ups noted below. The post-step is the right shape: release-please owns the SemVer-on-the-wire string, the normalizer owns the PEP 440 disk shape, and the two stay decoupled.

Things I checked

• release-please-config.json:9 — flipping versioning from default to prerelease with bump-minor-pre-major: true / bump-patch-for-minor-pre-major: false is internally consistent for the beta train: feat advances the prerelease ordinal off the current minor instead of going to 7.0.0-beta.1. Right call for where the SDK actually is.
• scripts/normalize_pyproject_prerelease.py:10-18 — both regexes anchor with ^...$ / fullmatch, the section gate at L49 prevents [tool.example] collateral damage, and the test at tests/test_normalize_pyproject_prerelease.py:22-42 proves it.
• Idempotency — normalize_pyproject returns False when the file is unchanged, and the workflow short-circuits at release-please.yml:39-42 (git diff --quiet) before attempting a commit. No empty commits, no push loop. Verified by the tests/test_normalize_pyproject_prerelease.py:45-51 second-call assertion.
• No infinite workflow loop — push targets release-please--branches--main, not main, and the workflow only triggers on push to main.
• Public API surface — none touched. src/adcp/** unchanged.
• Conventional commit prefix — both commits are ci:. Correct for release-please semver gating (non-bumping).

Follow-ups (non-blocking — file as issues)

• prs_created == 'true' may skip updates. code-reviewer flagged that release-please-action's prs_created output is only documented as 'true' when a new PR is opened. If subsequent merges to main cause release-please to update the existing release PR without re-emitting prs_created, the normalize step is skipped and pyproject.toml stays SemVer. Worth either pinning the docs read or gating on outputs.pr (non-empty JSON) / outputs.prs instead. Easy follow-up to file once we see one update cycle.
• Force-push race with release-please. The action rebuilds and force-pushes the release branch on every run. The normalize commit will get overwritten and replayed by the next workflow run. Happy path is fine, but there's a small window where the PR branch holds an invalid PEP 440 version. Belt-and-suspenders fix: also run normalize as the very first step of the publish job before python -m build, so the build never sees an un-normalized version even mid-race.
• Loud failure on unrecognized prerelease shapes. If release-please ever emits something the regex doesn't cover (-next.1, +build, etc.), the script silently no-ops and python -m build blows up downstream with a less obvious error. Validating with packaging.version.Version(...) after normalization and failing loud would localize the diagnosis.
• Tag vs. PyPI version drift. The git tag / GitHub release name stays SemVer (v6.1.0-beta.2) while PyPI shows 6.1.0b2. Not breaking, but the next time someone goes "which tag is on PyPI?" they'll have to map it. Either normalize the tag at release-please's manifest layer or note the mapping in the release-notes template.

Minor nits (non-blocking)

1. Comment the workflow step. A 2-line comment above release-please.yml:27 pointing to PEP 440 and the rationale would save the next maintainer from "simplifying" this away. Right now the why lives only in this PR description.
2. Idempotency test on already-PEP-440 input. tests/test_normalize_pyproject_prerelease.py covers the SemVer-in / no-op-on-second-call path but no explicit test that a [project] block already holding 7.0.0b1 is left alone. Currently the regex handles it because it requires the SemVer shape, but a regression on the regex would silently corrupt valid PEP 440 strings.

Safe to merge.