Release 0.2.0

[orgoca]

Version bump and CHANGELOG cut for the monotone-constraints release (#21, closing #8).

Why 0.2.0 rather than 0.1.2

Additive public API — two new keyword arguments (train_whitebox, build_artifact), three newly exported functions, a ninth validation check, and a new optional spec field. Backward-compatible new functionality is a MINOR bump under the SemVer this CHANGELOG commits to.

Backward compatibility, verified

schema_version stays 2 and the new model.monotone_constraints field is optional. I checked the real question — whether runtimes already deployed in the field cope — by extracting the v0.1.1 source tree from its tag and scoring a constrained artifact built by this branch using only the old runtime: it loaded, verified the hash, and returned byte-identical latent_int, band, and pd_ppm across 25 rows.

That was a manual check, so this PR adds the test that keeps it true: test_recorded_constraints_are_inert_to_scoring strips the field, re-hashes, and asserts identical integers and identical attribution. The field is governance metadata; it must never be an input to a decision.

Version plumbing, verified

The 0.1.0 release shipped a wheel whose __version__ said 0.1.0.dev0 while its PyPI metadata was correct. That is now structurally impossible — compileml.__version__ is the single source pyproject reads — but I confirmed it end to end anyway: built the wheel, installed it into a clean venv, and both compileml.__version__ and importlib.metadata.version('compileml') report 0.2.0.

To release after merging

git checkout main && git pull
git tag v0.2.0 && git push origin v0.2.0

Then publish a GitHub release on that tag — release.yml fires on release: published and pushes to PyPI via trusted publishing. If you want a rehearsal first, the workflow's workflow_dispatch → testpypi path builds and publishes to Test PyPI without touching the real index.