storage-cassandra: restore copy writes every item through the LWT put path #404

Observation

With #384, RestoreTableFromBackup on Cassandra copies the backup into the target through the ordinary put path (put_restored_item → put_item_impl), 8 items at a time (RESTORE_WRITE_CONCURRENCY). That path does a read of the existing item and a lightweight-transaction write per item, plus the synchronous GSI/LSI writes.

Measured on one host, a 60,000-item backup with no secondary indexes reaches ACTIVE after:

On a networked cluster with a multi-million-item table this is minutes to tens of minutes, during which the target is CREATING and DeleteTable/DeleteBackup on it are refused.

Why the LWT buys nothing here

The target is CREATING for the whole copy, so every data-plane request against it is refused; there is no concurrent writer whose write an LWT would have to serialize against. The read-before-write also finds nothing (the target is empty).

Proposal

A restore-only write path: plain INSERTs into the target's data table and each index table (unlogged batches grouped by partition, or just concurrent plain writes), skipping the read and the IF condition, and a higher write concurrency. Keep the item count check at the end. Going through the normal path was the right first step because it gets the index writes correct for free; the follow-up is to share the index-row projection with the put path and bypass the rest.

This is a performance follow-up to #384, not a correctness issue.