Declare CLI release compatibility

[raghubetina]

Summary

• declare the CLI prerelease compatibility contract
• coordinate the exact Foundation Plan format and service API range
• document protected, approval-gated npm publication

Verification

• branch commit was previously reviewed and tested in its dedicated worktree

This PR must merge before the Claude plugin package can be published.

[raghubetina]

Post-merge retrospective on the CLI's compatibility declaration: the prerelease contract naming the exact
Foundation Plan format and service API range it speaks, plus the protected approval-gated publication
procedure, landed as the explicit prerequisite for the plugin packaging (skills#21 consumed it). The
sequencing note in the body ("must merge before the Claude plugin package can be published") is the
dependency discipline that kept the three-repo release train ordered. The compatibility contract this PR
declared is the same structure the release/compatibility.json checks still verify today across the repos.
Nothing to flag retrospectively.

[raghubetina]

The shortest of the release PRs, and the concept it introduces underpins everything the other repos do:
a compatibility contract, declared before anything ships.

Three artifacts have to agree for First Draft to work end to end: the Foundation Plan format (a versioned
JSON schema, sketch/0.19), the service API (versioned separately), and this CLI. The contract this PR
declares says, in machine-checkable form, exactly which Plan format and which API range this CLI speaks.
From then on, "can we release plugin X with CLI Y against service Z" stops being a meeting and becomes a
lookup, and the repos grew tests that fail when someone changes one side of the triangle without the others.

Why declare it while everything is prerelease and changing weekly? Because the contract is cheapest to
introduce when it is trivially true. Retrofitting compatibility declarations onto already-divergent
artifacts means archaeology; declaring them on day one means every future divergence announces itself in a
failing check the moment it happens.

The Rails-world analogue you already know is the required_ruby_version in a gemspec plus a Gemfile's
version constraints: small declarations, checked mechanically, that turn "should work together" into "is
declared to work together." The habit scales from gems to whole product surfaces, as the three
First Draft repos have been demonstrating all month.