Explain the lifecycle of a write operation in LanceDB (versioning)?

Every write to a LanceDB table — whether it's adding rows, updating them, deleting them, or altering the schema — goes through the same fundamental lifecycle: new data files are written, and a new manifest describing the table's state is committed atomically, advancing the table to a new version.

Critically, existing data files from previous versions aren't deleted or overwritten during a normal write — even an update or delete works by writing new files (containing the updated data, or deletion markers for removed rows) and committing a new manifest that reflects the net effect, rather than mutating anything in place.

This append-oriented, immutable-file design is what makes time travel and checkout possible: because old files are still physically present until an explicit cleanup operation removes them, checking out an old version is simply a matter of reading the manifest for that version and following the files it references, rather than needing to reconstruct historical state from a separate change log.