Undo behavoiur

Calling .undo() does not update the head in the Hypercore, it returns a new Hyperbee that points to an old batch. However, it is writable. And writing on top of the new Hyperbee instance will append a batch to the Hypercore. This all makes sense at an implementation level but can lead to some potentially confusing behaviour for consumers of this library.

If, as I expect is normally the case, a user of this library simply opens a corestore path to use as a Hyperbee, then calling .undo() does not persist any rollback. However, calling undo() followed by flushing a WriteBatch will persist the rollback.

This either needs clearly documenting, or the undo (as exposed in the public API) should write a new batch without extra operations to persist the change so it is still applied next time the corestore path is opened.

Start by tracing the public .undo() API, the returned Hyperbee instance, and how a WriteBatch is flushed against the Hypercore and corestore path. Resolve whether undo should persist immediately or be documented as requiring a subsequent batch flush; done means the chosen behavior is explicit and remains consistent after reopening the corestore path.