Report compile and publication progress

[raghubetina]

Summary

• add stable First Draft: progress on stderr for analysis, Compilation, and GitHub Publication
• distinguish Compilation failure/cancellation from later GitHub failure/cancellation
• validate the service's closed Publication progress projection and sixteen-code safe reason allowlist
• reserve successful stdout for exactly the validated private GitHub repository URL
• preserve conditional singleton recovery and prohibit concurrent Compile invocations
• prepare ordinary @firstdraft.com/cli@0.1.0 for service API contract 0.2
• document the pre-1.0 policy: minor versions start breaking compatibility lines; patches are otherwise backward-compatible
• keep npm next as the approval-gated initial channel independently of version syntax, without moving latest

Verification

• npm ci --ignore-scripts
• npm audit (0 vulnerabilities)
• npm run check (typecheck, lint, format, 150 tests, pack check, packed executable smoke)

Coordination boundary

This is an unreleased ordinary 0.1.0 candidate requiring the First Draft API 0.2 service contract and the coordinated plugin 0.1.0 candidate. Exact candidate identities must pass the cross-repository compatibility gate before release. Merge, npm publication under next, any later latest promotion, plugin promotion, and service deployment remain separately serialized operations; this pull request performs none of them.

[raghubetina]

Post-merge retrospective. The service-side half of this contract was reviewed with skills#24; this is the
CLI half, and the split it enforces is exactly right for a scriptable tool: stable First Draft: progress
lines on stderr for the three phases, stdout reserved for exactly the validated final result, Compilation
failure distinguished from later GitHub Publication failure, and the service's progress projection validated
against a closed sixteen-code reason allowlist rather than echoed. Validating inbound progress (not just
rendering it) means a service that starts emitting an unknown phase fails loudly in the client instead of
printing something half-trusted. The stderr/stdout discipline has held through every later CLI change
reviewed above; the prefix and phase vocabulary are now load-bearing for users' scripts, which is what
"stable" was for. Nothing to flag.

[raghubetina]

A command-line tool has two output streams, and this PR treats the difference as an API contract, which is
what it actually is.

stdout is for the answer. When plan compile succeeds, stdout carries exactly the validated final result
and nothing else, so firstdraft plan compile | jq .repository works forever. stderr is for the journey:
First Draft: analysis..., First Draft: Compilation..., First Draft: GitHub Publication..., retry
timing, all the human-facing narration. Mix even one progress line into stdout and every script consuming
your output needs a fragile filter; the day you add a new progress message, those scripts break. The Unix
world settled this decades ago and tools still get it wrong weekly.

Second contract: name the phase in every failure. "Compilation failed" tells the user to fix their Plan.
"Compilation succeeded, Publication failed" tells them their app compiled fine and the GitHub step needs
attention, probably a retry or a permissions look. Collapsing those into one error message converts a
recoverable situation into a support ticket.

Third, subtlest: the CLI validates the progress the service sends against a closed projection (allowed
phases, sixteen safe reason codes) instead of relaying whatever arrives. A client that echoes its server
trusts the server's future forever; a client that validates has a contract that both sides can evolve
deliberately. When you write internal tools that wrap HTTP services, that validation layer is the difference
between a CLI and a fancy curl.