CHANGELOG sweep: split [0.2.0] from pre-pivot history

[trilamsr]

Problem

CHANGELOG.md [0.2.0] section (landed via #251) spans the entire pre-pivot Added / Changed / Fixed history (M1/M2/M4b/M8/M9/M11 add-rows, internal/* package add-rows, DCGM lifecycle migration, sentinel-error refactor). Many of these describe code that PR-F.1 (#206) / PR-F.2 (#215) / PR-K.2 (#217) — also listed under the same 0.2.0 heading — explicitly delete.

Honest history given there was never a 0.1.0 / 0.1.0-m9-alpha tag, but operators reading top-down can't tell what landed in v0.2.0 vs what was pre-pivot scaffolding.

Flagged by adversarial reviewer of #251 (low severity, kept out of scope per the 3-files contract).

Proposed fix

Sweep CHANGELOG into two sections:

• ## [0.2.0] - 2026-05-31 — keep only v0.2.0-net-user-visible: RFC-0013 pivot, OCB build, module/ submodule, OTel v0.130, otelcol_* self-tel rename, ko image, in-repo patterndetectorprocessor + rankjoinprocessor + nccl_hang detector, recipes, helm cleanup, deletion summary (one row per major delete wave, not per-package).
• New ## [0.1.0-m1] - <date> backdated section (or "pre-pivot scaffolding" footnote) — move all M1-M11 add-rows, internal/* add-rows, pre-pivot fixes there.

Acceptance

• ## [0.2.0] body reads top-to-bottom as a coherent v0.2.0 release note operators can review without prior pivot context.
• Pre-pivot Added rows for now-deleted packages no longer co-exist with the deletion entry under the same heading.

Out of scope

• Don't rewrite the ## [Unreleased] section.
• Don't backfill changelog entries for v0.1.0-m9-alpha (never released as a tag).