Verify the §9 rollback <5s commitment: run pg_snapshot_perf_smoke @ 1M rows on a representative cloud-class instance

[tonibergholm]

Why

snapshot-model.md §9 commits to rollback < 5 s @ 1M-row pgvector + 10 commits. The only measurement at that shape is 10.34 s on a laptop (batched-INSERT path, docs/architecture/benchmarks.md). The benchmarks doc explicitly frames laptop numbers as "a ranged signal, not an SLA" and names a representative-cloud-instance run as the unambiguous §9 commitment — pending since 2026-05-24 with no tracking artifact until this issue.

Until this run happens, the <5s figure is a target, not a verified commitment, and CLAUDE.md now says so (doc-truth reconciliation, 2026-07-10).

What

• Provision a representative cloud instance class (managed Postgres or equivalent — not Docker Desktop; the point is realistic fsync, shared_buffers, and network RTT).
• Run pg_snapshot_perf_smoke at BENCH_ROWS=1000000 against it.
• Record instance class, Postgres config, and numbers in docs/architecture/benchmarks.md.

If it still misses <5s

Per benchmarks.md "Coverage gaps": start with binary COPY (not text COPY — prototyped 2026-05-24, measured slower on laptop) before considering re-scoping §9. Re-scoping the target would need an ADR (ADR-0002 leans on §9).

Acceptance

• Cloud-class 1M-row rollback number recorded in benchmarks.md with instance class
• CLAUDE.md §9 paragraph updated: either "verified" (≤5s) or target re-scoped via ADR
• This issue referenced from the benchmarks.md coverage-gaps section is resolved

Needs a human: cloud credentials/billing. Filed as part of the 2026-07-10 doc-truth reconciliation.