This release contains a large number of bug fixes discovered by AI coding agents

• Fix a bug where MultimapValue::len() and is_empty() returned stale counts after
  consuming entries via next_back().
• Fix a bug where restore_savepoint() used in a non-Immediate durability transaction and when
  there are persistent savepoints newer than the one being restored, could fail
  with SavepointError::InvalidSavepoint, but the savepoint would actually be partially applied.
  The call now fails up front with SavepointError::ImmediateDurabilityRequired.
• Fix a bug in restore_savepoint() where modifications made earlier in the transaction might
  not be reverted.
• Fix a bug where renaming a table that was already modified in the same transaction could cause
  the database to become corrupted.
• Fix a bug where calling restore_savepoint() after modifying a table in the same
  transaction could cause the table to become corrupted in a future transaction.
• Fix a panic when delete_table() was called on a table that had been modified in the same
  transaction.
• Fix a panic in restore_savepoint() when passed a Savepoint from a different Database.
  SavepointError::InvalidSavepoint is now returned instead.
• Fix a bug where a transaction that created a persistent savepoint and was then
  aborted could cause the database file to grow excessively, until the Database was dropped.
• Fix a panic in check_integrity() when called while another transaction is still alive.
  DatabaseError::TransactionInProgress is now returned instead.
• Fix a bug where aborting a transaction that called restore_savepoint() with a savepoint
  when a newer savepoint existed could cause database space to be leaked.
• Fix a bug where aborting a transaction that called restore_savepoint() would leave more
  recent savepoints invalid.
• Improve performance when reading concurrently from multiple threads. Around 15% speedup on some benchmarks.
• Optimize cache usage, and general write performance. Around 1.5x speedup on some benchmarks.
• Optimize memory usage.
• Other performance optimizations.

• Implement Drop on AccessGuardMut and AccessGuardMutInPlace, which requires that these be dropped
  before the Table they borrow from.
  This fixes a critical bug where the accessor could outlive the Table, and be dropped after the
  transaction had already committed. This could cause data loss due to the data in the accessor
  being written out after the transaction had already completed.
• Remove Legacy type. To migrate off the Legacy type, use the Legacy type in the 3.x release
  and copy the data to a table with plain tuples, before upgrading to the 4.x release.

• Fix a data loss bug which can occur when the guard returned from Table::get_mut() is dropped
  after the transaction has been committed.
• Add a warning to Table::insert_reserve() indicating that it can cause data loss and recommending
  to upgrade to the 4.0.0 release.

• Reduce memory usage of open databases

• Fix panic which could occur when inserting into a table with fixed size keys when debug_assertions are enabled
• Add additional information to the stats returned by cache_stats()

• Implement std::error::Error for SetDurabilityError
• Fix compilation error on various non-tier-1 platforms, such as wasm32-unknown

• Fix performance issue where a transaction with a large number of writes would cause
  WriteTransaction::abort() and committing non-durable transactions to become slow

• Fix correctness issue with range(), extract_from_if(), and retain_in(). If a RangeBounds
  with start > end was passed as an argument and start and end keys were stored in different
  internal pages in the database (i.e. a sufficient condition is that more than 4KiB of key-value
  pairs were between the two keys) then these methods would perform as if the argument had been
  start..
• Fix performance regression, from redb 2.x, where Durability::None commits could become linearly
  slower during a series of transactions.

• Fix correctness issue with range(), extract_from_if(), and retain_in(). If a RangeBounds
  with start > end was passed as an argument and start and end keys were stored in different
  internal pages in the database (i.e. a sufficient condition is that more than 4KiB of key-value
  pairs were between the two keys) then these methods would perform as if the argument had been
  start..

• Fix correctness issue with range(), drain(), and drain_filter(). If a RangeBounds
  with start > end was passed as an argument and start and end keys were stored in different
  internal pages in the database (i.e. a sufficient condition is that more than 4KiB of key-value
  pairs were between the two keys) then these methods would perform as if the argument had been
  start..