Promote corrected Claude plugin 0.1.1

[raghubetina]

Summary

• select exact published @firstdraft.com/claude-code@0.1.1 for new marketplace installs
• record the protected tag, successful npm publication, immutable registry identity, and isolated direct-package check
• update release guidance and regression coverage while preserving the documented historical and qualification boundaries

Verification

• npm run check — 64/64 passed
• deterministic Claude plugin package check passed
• release-order reconciliation reports a coherent catalog identity
• protected tag claude-v0.1.1 peels to source commit 263326a47a502b56af7780093988c6b860b2d5d2
• publication run 31631531058 passed
• npm next is 0.1.1; npm latest remains 0.1.0-alpha.3

Boundary

This promotes already-published immutable package bytes. It does not move npm latest, publish the CLI, deploy the service, or prove the fresh two-command public marketplace install. That install remains a serialized post-merge observation against the exact merged catalog.

[raghubetina]

Post-merge review, hosted CI green. The promotion PR itself: the public catalog moves to exact published
@firstdraft.com/claude-code@0.1.1, and the record binds the protected tag, the successful npm publication,
the immutable registry identity, and an isolated direct-package check before the catalog changed. The order is
the important property (publish and verify the package, then repoint the catalog at what provably exists), and
it matches the package-first rule the release docs require. The "corrected" in the title refers to 0.1.1
fixing the 0.1.0 teaching-surface limitation documented in #30; the promotion does not rewrite that historical
record. Regression coverage was updated with the catalog change in the same merge, which the recovery rules
elsewhere require of any catalog repoint. Nothing to flag.

[raghubetina]

This PR is what actually ships a plugin version to the public, and the mechanism is worth seeing plainly: the
release is a one-line change to a JSON file.

The marketplace catalog (.claude-plugin/marketplace.json) is a pointer. Everyone who installs from the
public catalog gets whatever exact package it names. So "release 0.1.1" decomposes into: publish the immutable
package to npm (its identity is now a registry fact with a tarball hash), verify that exact package in
isolation, then merge the pointer change. The merge is the release, which is why the repo's rules treat a
catalog-manifest merge as a public mutation requiring its own authorization while ordinary merges are just
integration.

Notice what makes the pointer flip safe: everything it points to already existed and was already verified.
The direct-package check ran against the published tarball before the catalog moved, so the worst case of a
botched merge is a pointer to a good package. Compare deploying code and flipping a feature flag: teams
learned to separate shipping the bytes from activating them because a flip is instant and reversible while a
ship is neither. Same shape here.

One more habit: the promotion updated its structured compatibility assertions and regression tests in the
same merge. A pointer file with tests sounds excessive until the first time someone repoints it to a version
whose bundled CLI does not match the service, and the test catches it at review instead of at install time.