`table to remove should exist` when accessing database

Hi. I've been experimenting on my staging environment (silly me!) and at some point, perhaps on a StDB crash, it bricked my main module (which I didn't touch). Now, any access to it (even publishing) triggers this error:

thread 'tokio-runtime-worker' panicked at crates/datastore/src/locking_tx_datastore/committed_state.rs:362:18:
table to remove should exist
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::option::expect_failed
   3: spacetimedb_datastore::locking_tx_datastore::committed_state::CommittedState::replay_delete_by_rel
   4: <spacetimedb_datastore::locking_tx_datastore::datastore::ReplayVisitor<F> as spacetimedb_commitlog::payload::txdata::Visitor>::visit_delete
   5: spacetimedb_commitlog::payload::txdata::process_record
   6: spacetimedb_commitlog::payload::Decoder::consume_record
   7: spacetimedb_commitlog::commitlog::Generic<R,T>::fold_transactions_from
   8: <spacetimedb_durability::imp::local::Local<T> as spacetimedb_durability::History>::fold_transactions_from
   9: spacetimedb::db::relational_db::RelationalDB::open
  10: spacetimedb::host::host_controller::Host::try_init::{{closure}}::{{closure}}
  11: spacetimedb::host::host_controller::HostController::try_init_host::{{closure}}
  12: spacetimedb::host::host_controller::HostController::watch_maybe_launch_module_host::{{closure}}::{{closure}}::{{closure}}
<…tokio…>

Apparently, at some point it didn't finish writing some file (offset log? snapshot?) and since then it couldn't replay the commitlog.

I don't care for the lost staging data all that much, but this should make an example of one way StDB can break its state, so I'm posting this in hope to hear the possible reasons this has happened, with maybe steps to manually recover the data, and to hopefully implement a fix so that this will never happen in someone's production.

Start with crates/datastore/src/locking_tx_datastore/committed_state.rs at line 362 and trace replay_delete_by_rel through RelationalDB::open and the commitlog replay frames shown in the backtrace. Determine how the missing table state arises, document a recovery path if possible, and define a test or failure-handling change that prevents this panic during replay.