QE/FLE2 batched inserts only respect the stmtId of the first statement from an insert request and then increment it freely for each generated writes (instead of using kUninitializedStmtId/-1 for the auxiliary writes like other retryable internal transaction use cases).

So for example, an insert request with two statements (op1, op2) with stmtIds [1, 3] will end up using stmtIds[1, 2, 3] for the op1 (and its metadata writes) and stmtIds[4, 5, 6] for op2 (and its metadata writes). I haven't looked deep enough to tell whether this is actually a bug that would affect retryability from the user perspective. But this seems to violate how stmtIds are supposed to be handled in retryable internal transactions. More investigation needed to determine if this would manifest as a bug.