kv: reads from rolled back writes are not protected until commit time

**Describe the problem**

Some write operations also implicitly read the existing value, most notably:

- `ConditionalPut`: success depends on the previous value,
- `Delete`: The response's `FoundKey` field reveals the existence of the original value, and
- `Increment`: The resposne's `NewValue` field exposes the previous value.

On these, only ConditionalPut updates the timestamp cache and it only does so on error. The justification for not bumping the timestamp cache is that if the request successfully wrote an intent, then the implicit read does not need protection via the timestamp cache since no future writer can write under the intent.

However, assumption is incorrect if the write is later rolled back. A rolled back intent may be completely removed by a ResolveIntent request. Once the intent is removed, another writer is then free to write at a timestamp that may invalidate the read associated with the rolled back write.

The invalidate of that read amounts to a serialisation violation.

From SQL, I believe that the impact is that:

- Successful `INSERTS` observe the non-existence of keys in the primary or unique secondary indexes.
- `DELETE` observes the presence or non-presence of the existing row.

If those writes are rolled back, the related observations are not protected until commit time.

This problem has existed since savepoint rollbacks were added in 2019.

A partial solution to this problem would be to bump the timestamp cache anytime ResolveIntent completely removes an intent.

However, to fully fix the problem, we would also need to leave rolled-back intents in place until the transaction has reached a terminal state since before that point we do not know the timestamp that the transaction may commit at. Leaving these intents on disk may have additional performance implications that should be understood.

Start by tracing ConditionalPut, Delete, Increment, and ResolveIntent through the KV write and rollback paths. Determine how rolled-back intents affect timestamp-cache protection and whether intents must remain until terminal transaction state. Done means the serialization violation is fixed for rollback cases, with the performance implications understood.

Written by the indexing model from the issue text.