Rollback-Capable KV Store with Nested Transactions

Design and implement a key-value store that supports normal set / get / delete operations plus rollback of in-progress transactions. The Optimus variant specifically requires nested transaction rollback. Requirements Implement a key-value data structure with at least set(key, value), get(key), and delete / remove behavior. Add transaction support so an in-progress transaction can be cancelled and rolled back without corrupting committed state. Nested transactions must be supported: rolling back an inner transaction should restore the parent transaction's view, while rolling back the parent should discard all nested changes. The interface should make transaction boundaries explicit, such as begin(), commit(), and rollback(). Notes The key design choice is whether each transaction frame stores a full snapshot or only a delta log. A delta log is usually the expected direction: each frame records the first old value for every key it mutates, including a sentinel for missing keys. On rollback, replay the current frame's old values in reverse or restore from the saved first-touch map. On commit, merge the child frame's changes into the parent frame rather than immediately committing to the base store. The shortest bug path is losing information about keys that did not exist before a transaction. Use a distinct tombstone / missing marker instead of None if None can be a valid value. Nested commit should not mean globally durable commit unless the outermost transaction commits. A child frame can be folded into its parent, but parent rollback must still erase those child writes. This prompt is often framed as a KV store in one screen and as a nested-transaction data structure in another; prepare the same implementation to handle both. Preparation Implement the API twice: first with full snapshots to lock down semantics, then with per-frame first-touch deltas and a missing-value sentinel. Drill a trace with set, delete, begin, nested begin, child commit, parent rollback, and a key whose committed value is None. Be ready to state get complexity for a frame stack and the trade-off between merging frames on commit versus searching from top frame to base store.