Clarify plan status rejection boundary

[raghubetina]

Why

The error index grouped plan status with mutation commands, which implied that diagnostic-bearing analysis statuses could be server_rejected. The runtime instead treats every validated HTTP 200 analysis response as a successful read with exit 0 and reserves server_rejected for a validated non-authentication problem response.

Change

• Give plan status its own server_rejected row matching the runtime contract.
• Preserve the existing plan push and plan compile diagnostic boundary.

This changes documentation only. It does not change runtime behavior, package bytes, publication, release tags, promotion, or deployment.

Verification

• Node 24.18.0 and npm 11.16.0
• npm ci --ignore-scripts
• npm audit — 0 vulnerabilities
• npm run check — 154/154 tests plus typecheck, lint, formatting, package allowlist, and packed-package smoke
• node --test test/documentation.test.js test/plan-status.test.js — 26/26
• git diff --check

Documentation review was decision-summary-aware and found no blocking or follow-up issue.

[raghubetina]

Docs-only table fix, merged with green CI. Verified the claim against the runtime rather than taking the PR
body's word: in src/commands/plan-status.js, every HTTP 200 response goes down the parse-and-succeed path
regardless of what diagnostics the analysis body carries, and only a non-200 response with a validated problem
body returns responseKind: "problem" (which maps to server_rejected). The old table row, by grouping
plan status with plan push and plan compile, implied a 200 full of Plan diagnostics could exit nonzero.
The new dedicated row matches the code. Accurate, minimal, correct to split rather than reword the shared row,
since the two boundaries genuinely differ.

[raghubetina]

The distinction this one-row docs change protects: for a CLI, "the server told me your Plan has problems" and
"the server refused my request" are different outcomes that deserve different exit codes.

plan status asks the First Draft API how analysis of a pushed Plan went. If the answer arrives as HTTP 200,
the read succeeded, even when the analysis found a hundred diagnostics in the Plan. The CLI exits 0 and prints
them, the same way git status exits 0 while showing you a dirty tree. The command did its job; the news it
carried is a separate matter. Scripts depend on this: a wrapper that runs plan status in a loop should not
treat "your Plan needs work" as a crashed command.

server_rejected, exit 1, is reserved for the request itself being refused: a validated problem response with
a non-200 status (problem here means RFC 7807 application/problem+json, a standard shape for HTTP error
bodies that machines can parse). The mutation commands plan push and plan compile also use
server_rejected when the server rejects the submitted Plan, which is why the old table row lumped all three
together, and why that lump was misleading for the read-only command.

The general lesson for anyone writing a CLI: decide early what exit codes mean, write it down in an error
index like this repo's docs/errors.md, and treat mismatches between the docs and the runtime as bugs worth a
PR even when no code changes. Exit codes are an API; someone's cron job is parsing yours right now.