State the 0.x versioning rule and prepare the 0.2.0 changelog

[sehkone]

Context

The install layout, theme.toml, .meta, the INHERIT contract, the extra.pdf block, and the build-docs-pdf.sh interface all landed since 0.1.0. None of it has been adopted by a consumer yet — bootroot still pins 0.1.0 and runs the old .theme layout — so the contract is self-tested against the samples but unproven in the field. aimer-web builds two configs and already uses exclude_docs for content; agentcoop has neither a PDF build nor a docs/theme.toml. Either could force a base-config or layout change during adoption.

That is what 0.x is for, so the next release is 0.2.0, not 1.0.0. But the README's Versioning section defines MAJOR, MINOR, and PATCH without saying anything about 0.x, and those definitions assume 1.x semantics: under 0.x a breaking change conventionally bumps MINOR, which the section as written does not permit anyone to infer.

Scope

1. Add the 0.x rule to the README Versioning section: until 1.0.0, a breaking change bumps MINOR rather than MAJOR, and say briefly why the project is still on 0.x — the contract has not yet been proven by a consumer adopting it.
2. Promote the ## Unreleased section in CHANGELOG.md to ## [0.2.0] with the release date, and add the matching link reference beside the existing [0.1.0] one.

The Unreleased entries are already written and scoped by area. Do not rewrite them.

Acceptance criteria

• The README Versioning section states the 0.x rule and why the project is on 0.x.
• CHANGELOG.md has a ## [0.2.0] heading that release.yml can extract, and no empty ## Unreleased section is left behind.
• A [0.2.0] link reference exists alongside [0.1.0].
• markdownlint-cli2 passes; both files stay within the 80-column limit MD013 enforces.

Constraints

• Do not change the MAJOR, MINOR, or PATCH definitions themselves. Only add the 0.x qualifier.
• Do not edit the existing Unreleased entries, and do not add entries for repo-internal changes. The CHANGELOG documents the consumer-visible surface only.
• Do not create the tag. Tagging is a separate manual step.

[sehkone]

Deferred to the end of the queue. PR #32 implemented this and is closed unmerged — not because the work is wrong, but because it was sequenced too early: #33 changes build-docs-pdf.sh, which is release-surface, so it will add an entry to the very ## Unreleased section this issue promotes. Cut the heading once the content has stopped moving.

This is now the last step before tagging 0.2.0. Order: #33 and #34, then this, then the tag.

Two refinements to apply when it is picked up:

• The README paragraph should be four lines, not ten. The rule is the first sentence — below 1.0.0, a breaking change bumps MINOR — and it is load-bearing, because 0.2.0 is entirely breaking (the install path moved, the installer's argument interface is gone, extra.pdf_copyright is now an error) while the section as written defines MINOR as additive. A reader would draw the opposite conclusion. The rest — re-listing the contract's components and the closing sentence about what 1.0.0 means — is rationale that the surrounding sections already carry. Keep the clause stating that the project stays on 0.x until consumers have adopted the contract; that one answers a question that will be asked again.
• Check the date in the ## [0.2.0] heading against the day the tag actually goes out.

The closed PR's verification still applies and is worth repeating: run release.yml's extraction logic against the new heading before tagging. On the closed branch it resolved ## [0.2.0], stopped at ## [0.1.0], and yielded the scoped entries — which is the check that a tag will not fall back to a one-line release body.