docs: bring the launch material back in line with the server

[glatinone]

docs: bring the launch material back in line with the server

The v0.1.0 release notes, the dev.to draft and the Show HN draft were all written
before this chain, and three of their claims are now false in ways a reader would
act on:

• "Python only. No Node.js, Go, or Rust clients yet." There is a Node client;
  it has 22 tests and runs against a live server in CI.
• "ChromaDB is the only storage backend wired up." AMP_STORAGE_BACKEND=postgres
  shipped, verified in CI against a real pgvector container.
• "No authentication on the memory endpoints." Opt-in API keys shipped.

docs/release-notes-v0.1.0.md also claimed "70 server tests and 14 SDK tests".
It is 241 server tests, 31 Python SDK tests, 22 Node tests and 38 conformance
vectors, with the CI matrix worth describing: lint/format/type gates across every
package, Python 3.11 and 3.12, Node 18/20/22, a PostgreSQL service container, and
the conformance suite against a live server.

"The SDK is not on PyPI" was true but incomplete - npm is not published either -
and the "what's next" list still promised a Postgres adapter and stronger auth as
future work. Both are in this release; the list now says what is actually left
(scopes, expiry, rotation, OIDC) instead of re-announcing what shipped.

The "what's not here yet" section keeps its purpose and gets sharper: auth is
opt-in and keys-only, Postgres is verified in CI rather than on the reader's
machine, some state is per process, POST /lifecycle/run is all-or-nothing, and
the RFC's two v0.2 questions are named. A release note that only lists wins is not
useful to somebody deciding whether to adopt this.

The launch checklist gained a line recording the re-check, because catching
material that has drifted from the code is exactly what that list is for - and
these drafts will be published by hand, later, on a day when nobody re-reads the
server.

mkdocs build --strict clean; no stale claim remains in the launch material.

[glatinone]

Landed on master in the v0.1.0 chain: the branch was fast-forward merged as part of b940905..92b88ee and released as v0.1.0. Closing so the open list matches reality - the commits are in master, and the tag points at them.