storage-cassandra: two concurrent DeleteTable calls on one table both complete #553

Summary

On Cassandra two concurrent DeleteTable calls on one ACTIVE table both run to completion and both answer 200. The service answers one 200 and one ResourceInUseException Attempt to change a resource which is still in use: Table is being deleted: <name> (measured 2026-10-25, five rounds of five). #550 fixes the same pair on SQLite and MongoDB; PostgreSQL already serialized it.

Cause

crates/storage-cassandra/src/delete_table.rs never writes a DELETING status: it reads the row, drops the keyspace tables and deletes the catalog rows inside the request. Nothing fences the second call. The continuous_backups and tags deletes are keyed on the table name and ARN, so a CreateTable of the same name interleaved with the second call's tail can lose the new table's PITR row and tags.

Fix shape

A lightweight-transaction claim to DELETING as the first write (UPDATE ... SET table_status = 'DELETING' IF table_status = 'ACTIVE'); the loser answers TableBeingDeleted (added in #550). Key the continuous_backups and tags deletes on the table id, or run them before the claim is released. A direct test with ten rounds of two concurrent calls asserting one Ok and one TableBeingDeleted, and that a table re-created between the calls keeps its tags and PITR row.

Found while reviewing #505.