release: bump Opcore to 0.2.2

[EivMeyer]

Summary

Bump Opcore to 0.2.2 so the nested-workspace fix from #298 can actually reach users. npm view opcore version is 0.2.1 and the repo was 0.2.1, so promoting dev to main as-is would have short-circuited in release-publish.mjs with already published; ensuring dist-tag and shipped nothing.

The fix itself is #298, already merged to dev at ffc828c.

Changes

• All 17 workspace package versions and their exact internal dependency pins.
• Cargo workspace version, and artifactVersion in the three native metadata.json files. Binaries and checksums are untouched, and each binary still matches both its .sha256 and its metadata checksum. The CI native-artifact matrix rebuilds all three for the actual publish, the same way darwin-x64 was handled in 0.2.1.
• Hardcoded release version in scripts/check-workspace.mjs, scripts/release-dry-run.mjs, scripts/release-publish.mjs, plus RELEASE_VERSION and OPCORE_CONFIRM_PUBLISH in .github/workflows/release.yml.
• Runtime version constants in runtime-info.ts, timing.ts, graph/src/serve.ts, graph/src/artifact.ts, and asp-provider/src/protocol.ts. Left packages/opcore/src/try.ts alone: that 0.2.1 is the sample repo's own Cargo version, not ours.
• Five test assertions that pin the released version (opcore --version output and runtimeInfo.version, OPCORE_CONFIRM_PUBLISH, the unsupported-Windows message, and the ASP server manifest). Every other 0.2.1 in tests/ is an inert fixture and stays put.
• New docs/release/v0.2.2.md. The release workflow uses that file verbatim for the GitHub release, so it has to exist before main moves.
• CHANGELOG.md backfilled for 0.2.0 and 0.2.1, which both shipped without entries, plus the 0.2.2 entry.

Verification

Local, macOS darwin-arm64:

• node scripts/check-workspace.mjs passes at 0.2.2.
• OPCORE_REQUIRE_ALL_NATIVE_PACKAGES=1 npm run release:dry-run passes at 0.2.2.
• npm run graph-release:check and npm run release-receipt:check pass without regenerating receipts, which are content-checksummed rather than version-pinned.
• Built this branch and ran it against a two-package workspace: check --changed --repo packages/app reports opcore 0.2.2, runs 25 checks, catches the app's TS2322 at src/index.ts, and correctly excludes the sibling package. Before fix(validation): support nested Git workspace roots #298 the same command returned infrastructure_failure with zero checks executed.
• Test suites that the bump touched (asp-provider, graph-core-artifact, native-packaging-policy, opcore-facade): 101 tests, all passing after the assertion updates in e1d3d0b.

Correction

An earlier version of this description claimed the 7 full-suite failures I saw were environmental and reproduced on unmodified dev. That was wrong, and I had not finished the baseline run when I wrote it. The real numbers on this machine: unmodified dev fails 3 (ASP dogfood receipt, cutover release receipt, installed package bins, all needing packed artifacts or a pinned Ruff), and the bump added 4 more. Those 4 were genuine version-assertion failures, now fixed in e1d3d0b. CI is the authority.

One thing to decide before merging to main

crates/ has moved substantially since v0.2.1 (39 files), so the native binaries committed in git are stale relative to current dev. That predates this PR and is what #227 is about. It does not block publish, because the release workflow consumes CI native artifacts rather than the committed ones, but the in-repo binaries will not match what ships.

After this

Merge here, then open the dev -> main promotion PR. That promotion is where native-artifact and aggregate actually run, since both are gated on main. Merging it triggers main CI and the automated npm release for opcore@0.2.2.