docs: clarify crash-safe configuration constraints Clarify that the FileMmap requirement applies only when crash-safe recovery is enabled; with recovery disabled, factory modes remain unrestricted. Also state that convert_to_sst is fixed at factory creation so readers have a consistent expectation.
docs: clarify the wait-free read and crash-safety argument The process-crash model is a premise, not a step in the proof. Readers need to see why publication preserves a readable structure before following that argument across process boundaries. Separate structural consistency from read-side progress, and establish byte retention and relative addressing before deriving the isomorphism. Link the resulting argument and recovery guide to their English editions.
docs: explain wait-free reads and crash-safe isomorphism
docs: explain MemTable crash-safe recovery File mmap can preserve MemTable data across a process crash, but structure consistency alone does not establish a complete WriteBatch boundary. Recovery must know which prefix can be reused and where WAL replay resumes. Explain how the data-structure guarantees and the DB publication boundary fit together, so users can understand why large MemTables need not imply long recovery and how to enable this capability.