Investigate reports of failing to hotswap module when creating a new table

[bfops]

See https://discord.com/channels/931210784011321394/1067212802990813194/1262855827031851129 .

TL;DR:

• BitCraft update adds a new (private) table.
• Publishing without -c succeeds locally; new table survives StDB restart.
• Same succeeds to an "empty" BitCraft "staging" module on the same server running alpha-2.
  • No world uploaded.
  • No clients connected.
  • Did not test StDB restart, for obvious reasons.
• Publishing to proper alpha-2 module fails with following error:

  info: component 'rust-std' for target 'wasm32-unknown-unknown' is up to date
    Finished `release` profile [optimized] target(s) in 0.11s
  Optimising module with wasm-opt...
  Could not find wasm-opt to optimise the module.
  For best performance install wasm-opt from https://github.com/WebAssembly/binaryen/releases.
  Continuing with unoptimised module.
  Uploading to alpha-2 => http://playtest-live
  Publishing module...
  Error: failed to create table PlayerTimestampState: IndexError: Unique constraint violation 'idx_st_table_table_id_primary_key_auto_unique' in table 'st_table': column(s): '["table_id"]' value: 4097: Unique constraint violation 'idx_st_table_table_id_primary_key_auto_unique' in table 'st_table': column(s): '["table_id"]' value: 4097

• Failed publish disconnected all clients, though module survived intact and clients were able to immediately reconnect.
• Subsequently, publishes which did not contain any schema changes at all failed with the following error:

  Error: Database update rejected: incompatible schema changes for: ["ClimbRequirementDesc"]. See database log for details.

  • A cursory investigation by pgoldman 2024-07-16 suggests that this error is due to the allocated field sequence defs being incorrectly included in schemas when detecting incompatible schema changes.
  • Unlike the first, this failed publish did not disconnect clients.

Definition of done:

• Figure out why this happened, and why it didn't happen in any of the test/staging envs.
• At least, make it so that clients don't disconnect on a failed publish.
• Ideally, also make it so this case does not fail to publish.
  • Note that this is orthogonal to the above: even if this failure is removed, it's also important that a failed publish due to a schema mismatch (one that would require a migration) not disconnect clients.