Release v0.2.0: Vault Lab ships; release and method versions split

[SaMullinsJr]

Why

Tag v0.1.0 certifies a repository with no Lab in it; main's README leads with the Lab. Anyone downloading the release gets a different product than anyone browsing the repo. This is the GPT surface review's Priority 1 ("cut v0.2.0, not v0.1.1 — Vault Lab is a substantial new public surface").

The defect that blocked it

GPT's instruction was not executable as written, and this PR fixes why. check_version_parity.py welded eight files to one version string — including templates/vault.toml's method_version. Bumping everything to 0.2.0 pushes method_version out of the 0.1.x series that bvm-lint itself enforces (lint.py, BVM002), so the checker rejects its own templates and two conformance tests fail. Verified empirically before changing anything.

The weld was invisible at v0.1.0 because the method and the release were born together; the Lab is the first release where the two genuinely diverge.

The split

Track	Names	Files	Now
Release	what ships from this repo	pyproject.toml, bvm_lint.__version__, CITATION.cff, README badge, CHANGELOG.md	0.2.0
Method	the spec contract vaults declare via method_version	SPEC.md, templates/vault.toml, examples/…/vault.toml	0.1.0, unchanged

This is honest, not cosmetic: since v0.1.0, SPEC.md, src/, and schemas/ are byte-identical except for the SPEC.md status line (which said "release candidate" — stale since 2026-07-15). The method did not change; a teaching surface was added.

check_version_parity.py now enforces the two tracks separately and pins the method version to the 0.1.x series, with a new regression test for the series-escape case (all method files agreeing on 0.2.0 must still fail).

Against the review's five release items

1. Complete changelog entry — [0.2.0] documents the Lab, the fail-closed runner, the version-model split, and boundaries.
2. Corrected specification status — SPEC.md no longer says "release candidate"; its **Version:** stays 0.1.0.
3. Governing Vault Lab specification linked — lab/README.md gains a contract section: sealed build spec v0.3.0 cited by SHA-256 (2afb782d…), with the two required verbatim statements reproduced — checked against lab/tools/lab.py's actual strings.
4. Release-tag CI evidence — CI runs on this PR; after merge I'll tag v0.2.0 and cut the GitHub release with notes linking the tag's CI run.
5. Method vs Lab/release version distinction — the split above, stated in README, CHANGELOG, and enforced in code.

Verification

REPOSITORY VERIFY PASS
  68 tests OK (was 67; +1 series-escape regression)
  VERSION PARITY PASS (release 0.2.0, method 0.1.0)
  DIAGNOSTIC PARITY CHECK PASS (49 codes)
  RELEASE SURFACE CHECK PASS
  VAULT LAB CHECK PASS (5 cases, 4 scenarios, surfaces present)
  bvm-lint 0.2.0

After merge

I'll tag v0.2.0 on the merge commit and publish the GitHub release. Until then the safe public claim is unchanged: Vault Lab is available on unreleased main.