release-26.1: kvcoord: force split batch in txnWriteBuffer for mid txn flush

[yuzefovich]

Backport 1/1 commits from #161972 on behalf of @yuzefovich.

---

We just found a case where - if a BatchRequest with a CPut forces the txn write buffer to flush (e.g. because of buffer size limit) - we could lose some buffered writes in case that CPut's condition failed the evaluation. This was the case since we could have included the CPut into the same batch as all buffered writes, and the ConditionFailedError would make us discard the whole batch, whereas the higher level (i.e. SQL) could have discarded that error by using savepoints. To prevent this from happening we'll now require a separate batch for the buffered writes for all mid-txn flushes. Additionally, even in the end-txn flush batch case we now require a separate batch if a CPut is found.

Fixes: #161722.

Release note (bug fix): Previously, if buffered writes were enabled (which is a public preview feature, off by default), multi-stmt explicit txns that use SAVEPOINTs to recover from certain errors (like duplicate key value violations) could lose the writes that were performed before the savepoint was created in rare cases. The bug has been present since the buffered writes feature was added in 25.2 and is now fixed.

---

Release justification: bug fix.

[blathers-crl]

Thanks for opening a backport.

Before merging, please confirm that the change does not break backwards compatibility and otherwise complies with the backport policy. Include a brief release justification in the PR description explaining why the backport is appropriate. All backports must be reviewed by the TL for the owning area. While the stricter LTS policy does not yet apply, please exercise judgment and consider gating non-critical changes behind a disabled-by-default feature flag when appropriate.

[cockroach-teamcity]

This change is