docs: sync to v0.5.0 and carry the cutover's evidence forward

[mbeacom]

What and why

Post-release docs sync for v0.5.0, matching the #105 pattern from v0.4.0.

The site redeploys from main, and that ran seconds after #110 merged — before any
version string had moved. So adrkit.dev has been advertising v0.4.0 while npm
serves 0.5.0 since 13:16 today. That is the urgent half of this.

Two entries needed rewriting, not a version bump

README.md still described inbound markers as reaching adr explain "and
nothing else: adr check, the Action, and the Spec Kit context script do not scan
markers, so no CI semantics move." ADR-0022 reversed exactly that. The bullet now
describes the shipped scope, names ADR-0023's format rule, and states the
no-exit-code-authority property that makes the CI reach safe. It also credits all
three pull requests rather than only the first — @aballiet for #97 and #106,
@davesheffer for #109.

CLAUDE.md was headed "(v0.4.0 explain; check/CI extension proposed)"
and said "This branch proposes ADR-0022." #106 updated the body but not the
frame, and ADR-0023 landed afterward. Now says v0.5.0 shipped it, and points
readers at 0022 rather than the superseded 0021.

Things that moved and are easy to miss

• ci.mdx:79 named the commit v0 peels to (c3dff3a). That tag moved with
  the release; it is now c6bceac. Verified against git rev-list -n1 v0.
• DISTRIBUTION.md P1/P2 stated the MCP registry prerequisites as satisfied
  at 0.4.0. Re-stated against the published 0.5.0 package, and checked rather
  than assumed: npm view @adrkit/mcp@0.5.0 version → 0.5.0, and
  npm view @adrkit/mcp@0.5.0 mcpName → dev.adrkit/mcp. P2 is the one that
  failed at 0.2.0, because the registry reads mcpName from the published
  version rather than the working tree.
• RELEASING.md:12,17 told the next release that v0.4.0 was current and the
  immutable Action tag.

Evidence carried forward

RELEASING.md gains this cutover's two lessons, in the section that already
collects them:

• The publish dry-run skips the idempotency check, so it tries to republish a released adapter #104's dry-run failure is confirmed dry-run-only. Before tagging, the
  existing claim ("the real run skips the adapter") was checked instead of
  trusted: the registry's dist.shasum for @adrkit/spec-kit@0.1.2 was compared
  against the shasum the dry run had just packed. Exact match, integrity too. The
  real run then skipped the adapter and published only the four lockstep packages.
  The note records npm view <pkg>@<version> dist.shasum as the cheap way to turn
  "should skip" into "will skip" before tagging.
• The MCP registry has no step in release.yml. dev.adrkit/mcp keeps
  serving the previous version until a human publishes, which is how it is
  currently at 0.4.0 with 0.5.0 on npm. The note names the three prerequisites to
  re-check against the published package.

Also updated the git status-after-pack line to record that it was clean for
v0.5.0 as well.

Deliberately not in this PR

DISTRIBUTION.md §A submission status is untouched. It records a verified
outcome with dates and a registry response, so it gets written after the
registry publish, not in anticipation of it. The live registry currently returns:

dev.adrkit/mcp -> 0.2.1, 0.3.0, 0.4.0

Once mcp-publisher publish has run for 0.5.0, §A needs the re-publication date
and the verified response appended. Happy to do that as a one-line follow-up.

Verification

• bun run adr lint — 23 records, 0 errors, 0 warnings
• bun run --cwd site build — 33 pages built, and site/dist/index.html
  renders v0.5.0 on npm
• adr check README.md CLAUDE.md docs/RELEASING.md docs/DISTRIBUTION.md — clean,
  and notably no phantom marker declarations from the @adr references in
  these files' own prose and fenced examples, which is ADR-0023 doing its job on
  the repository that documents it

Note site/ needed its own bun install for the build; yaml was missing from
site/node_modules. That is a pre-existing local-setup detail, not something this
PR changes.

[Copilot]

Pull request overview

Synchronizes documentation and website content with the v0.5.0 release and records release evidence.

Changes:

• Updates published-version and Action-tag references.
• Documents expanded inbound-marker behavior.
• Records v0.5.0 release and registry lessons.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
README.md	Updates release status and marker scope.
CLAUDE.md	Documents shipped marker behavior.
docs/RELEASING.md	Adds v0.5.0 release evidence.
docs/DISTRIBUTION.md	Updates package prerequisites and tag SHA.
site/src/components/Hero.astro	Updates the homepage version.
site/src/content/docs/index.mdx	Updates the status band.
site/src/content/docs/quickstart.mdx	Updates the npm release callout.
site/src/content/docs/ci.mdx	Updates Action pinning guidance.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[mbeacom]

Both review comments accepted and fixed in b9192ba — they were the same class of defect this repo cares most about, documentation asserting something untrue.

README.md:234 — misdated the feature. Correct catch. "New in v0.5.0" dates the whole inbound-marker feature to this release, when v0.4.0 shipped it for adr explain under ADR-0021 and v0.5.0 extended it to check/CI and narrowed the grammar. Now reads "Expanded in v0.5.0" and says which release did which. This is the same mistake I flagged during the release PR, where the CHANGELOG claimed ADR-0021 "stands unedited" after ratification had moved its status and supersededBy — rewriting release history in a project whose subject is decision memory.

README.md:244 — overstated the guarantee. Also correct, and the worse of the two. I wrote that markers gain no exit-code authority "so nothing a pull request writes can fail a check." The second clause does not follow from the first and is false. checkChanges computes ok from error findings on changed ADR records:

const ok = !changedRecordFindings.some((finding) => finding.severity === 'error');

so a pull request that breaks a record it edits does fail, by design. The limit belongs to marker-derived information, not to authored content generally. Left as written, the README would have told readers adr check never fails on pull-request content — the opposite of its purpose. It now states the marker limit precisely and says what the check does fail on.

I also checked whether CLAUDE.md carried the same overbroad claim, since it has a parallel sentence. It does not — "Markers add governance context and findings but never gain exit-code authority" is already scoped to markers, so no change there.