Document stable CLI promotion

[raghubetina]

Summary

• document the completed 0.1.0 promotion to npm's default latest channel
• define stable completion around each candidate's explicitly named release-specific qualification while preserving full v14 service qualification as separate and incomplete
• make future release verification and promotion commands derive the exact version from the tagged checkout
• keep routine release checks read-only and prevent reuse of the consumed v0.1.0 tag or package version
• add regression coverage for the channel policy and safe operator path

Verification

• npm run check (151 tests plus typecheck, lint, formatting, package check, and packed smoke)
• npm audit (0 vulnerabilities)
• git diff --check
• live registry verification: latest=next=0.1.0

Boundary

This changes documentation and documentation-policy tests only. It does not change CLI runtime code, the publication workflow, package metadata, npm dist-tags, or any deployed service.

[raghubetina]

Post-merge review, hosted CI green. Documentation of the completed 0.1.0 latest promotion, with three
durable policy pieces: stable completion is defined per candidate by its explicitly named release-specific
qualification (full v14 service qualification stays separate and honestly incomplete); future verification and
promotion commands derive the exact version from the tagged checkout rather than a human retyping it; and the
consumed v0.1.0 tag is single-use. Routine release checks staying read-only matches the mutation discipline
reviewed across the other two repos. Nothing to flag; the derive-from-checkout rule in particular removed a
whole class of copy-paste release accidents.

[raghubetina]

Two small release-engineering habits in this PR pay off out of proportion to their size.

First: derive, do not retype. The promotion commands here take the version from the tagged checkout itself
(the tag names the version; the checkout proves the bytes), so no step involves a human typing "0.1.0" into a
command where "0.1.1" would silently do something else. Any value that appears in more than one place during a
release should have exactly one source and be derived everywhere else, which is the same normalization
instinct you apply to database columns.

Second: define done per release, in advance. "Stable completion" here means the candidate passed its
explicitly named release-specific qualification, written down before publication. Without a named finish line,
release quality degrades into "CI was green and nobody objected." Note also what the docs refuse to claim: the
full v14 service qualification is recorded as separate and incomplete, right next to the promotion it might
have been tempting to fold it into. A release document that can say "this part is not proven" is one you can
trust about the parts it says are.

And the consumed tag rule: v0.1.0 is spent. If the bytes ever need to change, that is v0.1.1, because a
tag that can be moved is a name, and release identities must be facts.