Prepare plugin 0.1.0 release candidate

[raghubetina]

Summary

• distinguish application Compilation from retained GitHub Publication progress and render only allowlisted phases, retry timing, and safe reason codes
• preserve structured final CLI errors while teaching safe singleton recovery only after the prior Compile invocation exits
• adopt ordinary plugin 0.1.0 with the pre-1.0 minor-breaking/patch-compatible policy and no compatibility aliases
• pin the exact published CLI 0.1.0 main revision and API-contract 0.2.x compatibility line
• keep npm next as an approval-gated channel independent of SemVer and leave latest and the public marketplace catalog unchanged
• make plugin publication OIDC-only, rehearse registry/tag/catalog ordering before tagging, and reconcile consumed identities against the immutable protected-tag compatibility bytes

Verification

• 61/61 repository tests
• npm audit: 0 vulnerabilities
• exact CLI contract and deterministic plugin package checks against d37d8b6775a0b97ce10bd651485bd308fed1dda2
• live read-only prospective npm/protected-tag/catalog reconciliation
• Skill validator and gh skill publish --dry-run
• final max-effort independent review: approved, no material findings

Candidate identity

• plugin version: 0.1.0
• plugin tarball SHA-256: 02fad6cd2207f3d2ab7598f0aa67825520ebc5b807294e0c241774ee3ac6a89d
• Skills runtime digest: 8506cad9c9e4e6739f39d95a4e2cfb84b5e0ca63bd05ddec06400c7f27d0b835
• compatibility document SHA-256: 5d2d8de815c8d90761171bc42ef10f3e3635f4ed4614fa257d3c921b305acdab

Release boundary

This remains a draft source-integration PR. The public catalog still serves plugin alpha.3, npm latest is not moved, and this PR does not authorize or perform a plugin publication, release tag, catalog promotion, service deployment, API-contract activation, or staging mutation. Service API 0.2 activation and plugin 0.1.0 publication/promotion remain an explicitly approved and announced maintenance-window sequence.

[raghubetina]

Post-merge retrospective. Three durable pieces landed here. The progress-rendering contract (allowlisted
phases, retry timing, and a closed set of safe reason codes, distinguishing Compilation failure from later
GitHub Publication failure) is the client half of the contract cli#21 implements, and the allowlist direction
is the right one for a surface that relays service internals to a user terminal. The singleton-recovery
teaching (only after the prior Compile invocation exits) is the seed of the replay exception that #41's
release policy later formalized. And the version decision (ordinary 0.1.0 with the pre-1.0 minor-breaking
convention) set the SemVer posture the compatibility matrix still uses. Consistent then, consistent now.

[raghubetina]

The design choice to study in this candidate PR: progress reporting through an allowlist.

A CLI relaying a service's progress could just print whatever the service sends. This PR does the opposite:
the client renders only phases it knows (an enumerated projection), retry timing, and reason codes from a
closed safe list. Anything the service adds later, or any internal detail that leaks into a message, simply
does not render until a client release deliberately admits it. Blocklists fail open (the thing nobody
anticipated gets through); allowlists fail closed (the thing nobody anticipated is withheld). For a surface
that might otherwise echo internal hostnames, stack fragments, or half-formed states into a user's terminal
and their pasted bug reports, failing closed is the right default, at the cost of a release step when new
phases appear.

Second idea: the failure taxonomy distinguishes where in the pipeline you failed. "Compilation failed" and
"Compilation succeeded, GitHub Publication failed" demand different user responses (fix your Plan versus
check your repository state), so they are different outcomes with different codes, not one sad message.

Third: recovery teaching with a precondition. The safe replay is taught as available only after the prior
invocation exits, because two concurrent invocations racing one singleton is exactly the ambiguity the
recovery exists to resolve. Teaching users when a recovery is safe is part of the recovery's design.