kvcoord/kvserver: pre-emptive refresh not possible for some buffered writes transactions.

**Describe the problem**

In a transaction with write buffering enabled, many writes are replaced with a locking read and the write is buffered until it can be flushed during EndTxn.

Unlike a write, however, the locking Get requests we use in this case do not apply the timestamp cache. As a result read-write conflicts are not detected until we do flush the Put as part of the final EndTxn batch.

This has at least two possible problems:

1. Detecting the need to move the WriteTimestamp late means that on commit we evaluate all of the writes, evaluate the endtxn, return an error to the coord sender, do the refresh anyway and then retry the final batch. This seems like it would be substantially more expensive than doing the refresh straightaway.

2. Our observability surfaces around transaction conflicts are well-integrated into the pre-emptive refresh path but not the "refresh on failed endtxn" path.

(2) should probably be solved in general as it doesn't just impact buffered writes transactions. For (1) we've previously discussed allowing the client to somehow indicate that a locking get should apply the timestamp cache.

Jira issue: CRDB-50683