[Bug] Cassandra: ConsistentRead true is served at ONE against writes committed at ONE #560

Describe the bug

The Cassandra backend serves a ConsistentRead: true GetItem, Query or Scan at the driver's default consistency level, ONE, and commits its base-row writes at ONE as well. With the default keyspace replication factor of 3, one replica acknowledges the write and one replica answers the read, so a read can return the item as it was before a PutItem that the client already saw succeed. The service guarantees that a strongly consistent read reflects every write acknowledged before it started.

The statements involved, read from the source at main (744ea291):

• Reads: get_item_impl, query_impl and scan_impl under crates/storage-cassandra/src/data/ issue their statements with no consistency level, so the driver default applies. cassandra_protocol 4.0.1 marks Consistency::One as the default, and crates/storage-cassandra/src/cassandra_util.rs says so of query_rows ("uses the driver's default consistency, which is ONE").
• Writes acknowledged at ONE: the OCC write lightweight transaction (data/update_item.rs, occ_write), put_item_if_not_exists (data/put_get_item.rs), the plain DELETE for a table with no index, stream or TTL (data/delete_item.rs), and the TransactWriteItems commit statement (data/transactions.rs). For a lightweight transaction the statement's consistency is the commit consistency, so the commit is acknowledged by one replica.
• Writes at LOCAL_QUORUM: the conditional delete (query_lwt), the secondary-effects batches and the TTL-claim path.

get_item_quorum in data/put_get_item.rs exists for the TTL worker and reads at LOCAL_QUORUM; the request path does not use it.

Since #559 the flag reaches the backend as ReadOptions::consistent_read, so the routing has somewhere to hang; the backend does not act on it yet.

To Reproduce

1. Start ExtendDB on the Cassandra backend against a three-node cluster (or a single node with the keyspace replication factor left at the default 3 and nodetool used to pause one node).
2. PutItem an item; on success, GetItem the same key with ConsistentRead: true in a tight loop.
3. With one replica lagging (the paused node resumed, or under write load), observe a GetItem that returns the previous item or no item.

A single-node cluster with replication factor 1 does not show it: one replica holds every write.

Expected behavior

A ConsistentRead: true read reflects every write acknowledged before it started. On Cassandra that needs read and write levels that intersect within the datacenter: base-row writes acknowledged at LOCAL_QUORUM (the lightweight transactions at commit consistency LOCAL_QUORUM, as query_lwt already sets; the plain DELETE; the transaction commit statements) and true reads at LOCAL_QUORUM. false reads can stay at LOCAL_ONE.

Actual behavior

Reads and base-row writes run at ONE. Two replicas plus one replica is three, which does not exceed the replication factor of three, so the read set and the write set can be disjoint.

Environment

• ExtendDB version: main at 744ea291 (0.1.14), read from the source
• Operating system: any
• Deployment method: source

Additional context

Raising the read level alone (a LOCAL_QUORUM or LOCAL_SERIAL read for true) does not close the gap while the writes commit at ONE: a non-serial quorum read does not consult Paxos state, and the plain DELETE and the batches are not Paxos writes. The write side has to move with it, which changes write latency for every base-row write; that is the trade this issue asks the backend owners to make.

ADR-0024 (in #559) names this gap under Consequences. The doc comment on CassandraEngine::get_item on that branch states the current levels.

Checklist

• I have searched existing issues for duplicates
• I have included the ExtendDB version and environment details
• I can reproduce this with the latest release (derived from the source and the driver default; not reproduced on a cluster)