Document the unanswered-commit case in transactional persistence

[tobiajo]

Documents the transactional mode's one failure that is not a rejection: an unanswered commit. If commitTransaction times out client-side it surfaces as the client's TimeoutException, not the CommitFailedException of a fenced write, and the broker may have committed anyway.

• Nothing is lost either way: the input offset rides the same transaction, so snapshot and offset commit together or not at all.
• The flush does not retry it — legal per the client contract, but each attempt would block up to max.block.ms inside the poll cycle, risking a silent eviction at max.poll.interval.ms — and abortTransaction throws rather than aborting while a commit is unresolved (commitBatch already discards that throw). The producer is unusable until rebuilt: only a retry of that same commit acks the client's pending transition, and nothing clears it in the background.
• Under the default ignorePersistErrors = false the failure tears the flow down and the new producer's initTransactions settles the transaction. Under ignorePersistErrors = true it is swallowed instead, so the partition stops persisting and stops advancing offsets until the flow restarts — at the next rebalance, or sooner if a later offset commit through the spent producer crashes it. Frozen and self-consistent, not corrupted.

Documented as a bullet in the transactional section, next to the failure mode it most resembles (a recovery read that fails loudly), rather than under rejected writes — it is not one.

GroupCommitSpec pins the kafka-flow half: the timeout surfaces unchanged, kafka-flow never retries the commit, and the cleanup abort is attempted without its own outcome replacing the timeout. No production code changes.

The client contract, and a measurement of it against a broker paused mid-commit, are pinned as ext(K16) in the research corpus (#835). That harness is not checked in: it pins a kafka-clients contract rather than kafka-flow behavior.