[P3][docs] Define the production arc: the concrete bar from test/dev to production data

[cevheri]

Summary

Roadmap item (DESIGN.md section 7, still-open question: "Production arc — define the concrete bar that moves LibreDB from test/dev to earns production data"). v0.2.0 closed much of what the audit named (IO-failure latch, exclusive lock, foreign-file refusal, corruption refusal, directory fsync, provenance); this issue is about writing down what REMAINS between "early beta for test/dev" and an honest production recommendation, so the claim is a checklist rather than a feeling.

Candidate bar (to be debated and ratified in DESIGN.md)

• WAL compaction shipped (Add WAL compaction to reclaim space and bound recovery time #12) — unbounded file growth is disqualifying for long-lived data.
• Real-browser OPFS verification (Verify OPFS browser persistence end-to-end on Chrome, Firefox, and Safari #10) if the browser is in the supported production surface.
• A documented crash-consistency soak (long DST runs as a release ritual; LIBREDB_DST_SEEDS already supports it).
• Memory ceiling guidance hardened from prose to numbers (the store is in-RAM by design — production means stating the tested envelope).
• Backup story exercised (file-copy rule documented; consider doctor [P3][cli] Add a libredb doctor command for non-mutating file diagnosis #51 as the pre-backup check).
• A stability promise for the on-disk format (v1 header shipped; state the compatibility policy explicitly).

Deliverable

A dated DESIGN.md section 7 resolution (like the line-count resolutions): the checklist, what is already met, and what release milestone flips the README status from early beta.

Constraints

• Docs/design work only; no code. The output is a ratified decision, not marketing.