Non-frozen list insert operations replicated incorrectly

As far as I understand, the replicator replicates these operations using INSERT, which causes Scylla to generate the list's timeuuid keys internally - in particular, the operation is not idempotent.

Non-frozen list modifications must always be replicated using UPDATE ... SET l[SCYLLA_TIMEUUID_LIST_INDEX(...)] = ..., so that the key is provided by the client, which makes the operation idempotent and ensures that the order of elements in the replicated list is the same as in the original list.

To replicate an INSERT operation, we can do something like this:

begin unlogged batch
insert into ks.t (pk, ck) values (0, 0);
update ks.t set v[scylla_timeuuid_list_index(...)] = ... where pk = 0 and ck = 0;
apply batch

so we use a separate insert to create the row marker, but update to create the list elements.

Trace the replicator's handling of non-frozen list operations and the INSERT path described in the issue. Verify how row creation and list element writes are emitted, then confirm completion when replication supplies the client-side timeuuid keys and preserves idempotence and element order.