Docs: soften Table API atomicity wording per review

upsert may produce more than one snapshot while still committing
atomically, so describe the Table API as committing atomically rather
than as a single snapshot.

Author: iSparshP

mkdocs/docs/api.md

@@ -369,7 +369,7 @@ for buf in tbl.scan().to_arrow_batch_reader():
 
 Every write operation is available through two APIs.
 
-The **`Table` API** exposes each operation directly on the table object: `tbl.append(...)`, `tbl.overwrite(...)`, `tbl.delete(...)`, `tbl.dynamic_partition_overwrite(...)` and `tbl.upsert(...)`. Each call opens a transaction, applies the single operation, and commits it as one atomic snapshot. This is the simplest mode and the right default when you only need a single write.
+The **`Table` API** exposes each operation directly on the table object: `tbl.append(...)`, `tbl.overwrite(...)`, `tbl.delete(...)`, `tbl.dynamic_partition_overwrite(...)` and `tbl.upsert(...)`. Each call opens a transaction, applies the operation, and commits atomically. This is the simplest mode and the right default when you only need a single write.
 
 The **`Transaction` API** exposes the same operations on a transaction object obtained from `tbl.transaction()`. It batches multiple operations into a single atomic commit: either every operation becomes visible together, or, on failure, none of them do, and readers never observe an intermediate state.