Require stable npm release defaults

[raghubetina]

Summary

• record the explicitly approved stable npm dist-tag promotion for plugin 0.1.1 and CLI 0.1.0
• preserve historical alpha observations as time-bounded evidence while correcting current-state documentation
• require release-specific qualification, catalog/next/latest reconciliation, and an explicit rollback dist-tag disposition

Verification

• node --test test/release-compatibility.test.mjs (6/6)
• sh script/check (64/64)
• node script/check-plugin-release-order.mjs --prospective (coherent consumed 0.1.1 catalog identity)

Boundaries

This change publishes no package bytes and changes no npm dist-tag, catalog source, service, deployment, repository, or Codespace. Existing-install update behavior, the authenticated template-and-Codespace journey, and full v14 qualification remain unproved.

[raghubetina]

Post-merge review, hosted CI green. Records the explicitly approved stable dist-tag promotion (plugin 0.1.1,
CLI 0.1.0) and does the two things a promotion record should do: correct current-state docs to the new
reality, and preserve the alpha-era observations as time-bounded historical evidence rather than deleting or
rewriting them. The added requirement that a rollback names its dist-tag disposition in advance closes a real
gap; rollback plans that only name the code revision leave the registry pointer ambiguous at exactly the
moment nobody wants ambiguity. Consistent with the reconciliation rules later consolidated in #41.

[raghubetina]

When a release goes stable, the paperwork has two jobs, and this PR shows both done correctly.

Job one: flip the present tense. Every current-state surface (README status tables, compatibility JSON,
release docs) now says 0.1.1 is what new users get. Job two, subtler: do not falsify the past while doing it.
The alpha-era observations stay in the record, labeled as time-bounded evidence: "on this date, latest
selected alpha.3" remains true forever as a statement about that date. Deleting old observations because they
no longer describe the present confuses two kinds of truth, and repos that do it lose the ability to answer
"what did users actually experience in week two."

The third piece is the rollback rule: any rollback plan must state its dist-tag disposition up front. Where
does latest point if we roll back, and where does next? A rollback that names only the git revision leaves
the npm pointers as an improvisation during an incident. Deciding pointer disposition while calm is the
release-engineering version of writing your down migration when you write your up.