Route CLI documentation by task

[raghubetina]

Summary

• reduce the public README from 23.1 KB to 4.5 KB and keep the shortest supported journey visible
• route detailed command, recovery, release-policy, and dated-history knowledge to distinct owners
• add repository-wide documentation link checks and explicitly keep repository docs outside the npm package

Verification

• npm run check — 153/153 tests plus typecheck, lint, formatting, package allowlist, and packed smoke
• npm audit — 0 vulnerabilities
• npm pack --dry-run --json --ignore-scripts — 20 entries, no docs/
• independent documentation review — pass, no remaining findings

Boundaries

This changes documentation and documentation/package-boundary checks only. It does not change CLI runtime behavior, versions, package contents, dist-tags, publication state, or release authorization.

[raghubetina]

Post-merge review, hosted CI green (153/153, packed smoke shows 20 entries with no docs/). A README diet
from 23.1 KB to 4.5 KB with the detail routed to dedicated owners (docs/commands.md, docs/errors.md,
release policy, dated history), plus repository-wide link checks. The explicit decision to keep repository
docs out of the npm package was reversed one PR later by cli#25, which packaged a version-matched docs set;
that is an evolution rather than a contradiction (this PR removed the accidental inclusion, #25 added a
deliberate, verified one), but readers of this diff should know the exclusion did not survive as stated.

The keeper here is "shortest supported journey stays visible": after the diet, the README still shows a
complete install-to-success path inline. A router page that routes everything, including the happy path, makes
the reader click three times before their first command; keeping the golden path inline while routing the
long tail is the right balance for a CLI.

[raghubetina]

A 23 KB README is not impressive, it is unread. This PR cuts one to 4.5 KB and the interesting part is
deciding what earns a place on the shrunken page.

The principle used here: the README keeps the shortest supported journey (install, authenticate, push a plan,
compile) visible inline, and routes everything else to a page that owns exactly one topic. Commands get
docs/commands.md, exit codes get docs/errors.md, release policy and dated history get their own files. One
topic per page means one place to update, which means fewer half-updated duplicates, which is where most doc
rot starts.

Two reinforcements make the structure durable rather than aspirational. Link checks run repository-wide in CI,
so a renamed file breaks the build instead of a reader. And the packed-package test asserts the npm tarball's
exact file list, so repository-internal docs do not leak into what users download (a follow-up PR later
shipped a deliberate, version-matched docs set instead; the lesson stands either way, ship things on purpose,
not by glob accident).

Why care about README size at all? Two audiences share that file: a human deciding in ninety seconds whether
your tool is worth trying, and increasingly an AI agent with a context budget reading it to learn your CLI.
Both are best served by the same thing, the golden path up front and the encyclopedia behind links. If your
README has grown past what a new reader consumes in one sitting, split by topic ownership, not by section
headings.