Cassandra: PutItem of an item whose index keys are unchanged deletes its GSI and LSI rows #742

On the Cassandra backend, a PutItem (or UpdateItem) of an existing item whose GSI/LSI key attributes are unchanged leaves the item's index rows deleted.

Mechanism: crates/storage-cassandra/src/data/index.rs::sync_indexes (and the GSI worker's gsi_apply_index in workers.rs) adds a DELETE of the old index row and an INSERT of the new index row to one logged batch. When the old and new items produce the same index row key, both statements address the same row; every statement of a logged batch carries the same timestamp, and on a timestamp tie Cassandra's tombstone wins, so the INSERT is shadowed and the row is gone.

Reproduced on the release binary (the write path unchanged since f49c5f82 on main): CreateTable with a GSI and an LSI; PutItem of one item; Query on the GSI and on the LSI each answer 1; the same PutItem again; both answer 0; cqlsh SELECT COUNT(*) of both index tables answers 0. A later distinct item with the same GSI key queries as 1, so the base write path is fine; only the re-put item loses its index rows.

Found while reviewing #740 (the restore job), whose resume on Cassandra re-applies at most one batch of items after a crash and so hits this on a table no client has written yet; #740 carries a fix in sync_indexes/gsi_apply_index (skip the DELETE when the old and new index rows are the same row) with storage and wire tests. Filed separately because the defect is main's write path and affects every PutItem/UpdateItem on Cassandra, not only restores.