feat!: close cluster A and prepare the 3.0.0 release

[isayev]

Finishes cluster A (plan: #130) and does the version work.

m6 — the derived multiplicity was never checked

Both the bounds and parity checks in _resolve_multiplicity sit inside if mol.HasProp("multiplicity"), so a multiplicity Auto3D derived from the radical-electron count came back unchecked. 2S+1 requires odd multiplicity for an even-electron species and even for an odd-electron one — which the radical count can violate when a valence-satisfied drawing hides an open shell. Wrong by one step is R·ln 3 = 0.65 kcal/mol in T·S_elec.

Warn-only, deliberately. Unlike the supplied-value branch, this is the fallback — there is nothing further to fall back to. Substituting a parity-consistent guess would replace a wrong number the user can see with one they cannot.

RDKit re-derives radical electrons on sanitization and is self-consistent for every ordinary species — CH₂, CH₃, O₂, N and ethanol were checked and none trip it — so the test forces the inconsistency. That is also the argument for the check: the case it catches is the one no ordinary input produces.

L5 — k=True passed every gate and meant k=1

bool subclasses int, so operator.ge(True, 1) is True and the bounds check let it through; top_k's if k == 1 then matched. Harmless in effect, but k: int | bool = False advertises a bool where only False was ever meant as a sentinel, so True was a value the type called legal and nothing gave a meaning to. Rejected rather than reinterpreted — a caller who wrote it meant something, and it was not "one conformer". k=False keeps working, since that is how "use window instead" is spelled.

L6 — one parameter name, two meanings 80× apart

batchsize_atoms is a per-gigabyte multiplier in main()/Auto3DOptions and absolute in opt_geometry: the default 1024 means 81,920 on an 80 GB card through one entry point and 1024 through the other. Both docstrings now state which they are, rather than one cross-referencing the other. Documented rather than unified, because unifying changes memory sizing for existing callers.

Release preparation

Shipping 3.0.0, not 4.0.0: no 3.x ever reached PyPI or conda-forge, so 2.3.1 → 3.0.0 is a plain major bump rather than a gap users have to explain to themselves.

• pyproject.toml: 3.5.0 → 3.0.0.
• The unreleased CHANGELOG section is retitled [3.0.0].
• The two never-shipped sections become [3.5.0-dev] and [3.0.0-dev], each marked never published with a note explaining it. Content preserved; the version collision is gone.
• The v3.0.0 and v3.5.0 tags are deleted, locally and on the remote. They matched no published artifact, and leaving v3.0.0 on old code while publishing a different 3.0.0 is worse than removing it. The five v2.* tags are kept — each matches a real PyPI or conda-forge release. v3.0.0 gets re-created at the release commit.

The CHANGELOG disagreed with the package index in both directions

Found while doing the above, and fixed in the same pass:

version	CHANGELOG	published
2.3.1	missing	PyPI 2024-08-13
2.3.0	missing	PyPI + conda-forge 2024-08-02
2.2.10	present	never published (PyPI went 2.2.9 → 2.3.0)

[2.3.0] and [2.3.1] are added with their real upload dates read from the index, not guessed — I had invented plausible dates on the first attempt and replaced them once I checked. [2.2.10] is marked never published. [2.2.9]'s hand-written date disagrees with PyPI's record by a month; that is noted in place rather than silently overwritten, since someone wrote it deliberately.

Verification

• Both behavioral fixes mutation-verified: dropping the True rejection fails the L5 test; dropping the parity warning fails the m6 test.
• Each has a companion test asserting the new branch does not fire on valid input — four ordinary radicals stay quiet, and a real k is unaffected.
• 1289 passed, 9 skipped; ruff clean.

Cluster A is now closed. L4 (check_connectivity has no opinion on element-table misses) is the one item left, and it is documented-by-design rather than a defect — recommend closing it as such rather than fixing.