MINOR: Document transaction.timeout.ms behavior under EOS in Streams config guide (#22067)

The Streams configuration guide already lists transaction.timeout.ms and
its default, but it is easy to overlook when enabling exactly-once
processing. This adds a short note directly under the
processing.guarantee section to make it more obvious that users should
consider the transaction timeout when tuning EOS applications, including
the broker-side constraint (transaction.max.timeout.ms) and the
trade-offs of increasing the value.

Reviewers: Andrew Schofield <aschofield@confluent.io>

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Author: lucasbru

docs/streams/developer-guide/config-streams.md

@@ -1589,6 +1589,8 @@ Serde for the inner class of a windowed record. Must implement the `Serde` inter
 > Recommendation:
 >     While it is technically possible to use EOS with any replication factor, using a replication factor lower than 3 effectively voids EOS. Thus it is strongly recommended to use a replication factor of 3 (together with `min.in.sync.replicas=2`). This recommendation applies to all topics (i.e. `__transaction_state`, `__consumer_offsets`, Kafka Streams internal topics, and user topics).
 
+> When exactly-once processing is enabled, Kafka Streams sets `transaction.timeout.ms` to 10000 (10 seconds) by default. This bounds how long a transaction may remain open before the broker aborts it and fences the producer. If your application requires longer processing times per poll-process-commit cycle, you can increase this value via `StreamsConfig.producerPrefix(ProducerConfig.TRANSACTION_TIMEOUT_CONFIG)`, but note that when EOS is enabled Kafka Streams also requires `transaction.timeout.ms` to be greater than or equal to `commit.interval.ms`, otherwise the application will fail to start. In addition, the value must not exceed the broker's `transaction.max.timeout.ms`. Keep in mind that a higher transaction timeout delays fencing of zombie producers and may extend how long `read_committed` consumers block on uncommitted data, so it should only be increased when necessary.
+
 ### processor.wrapper.class
 
 > A class or class name implementing the `ProcessorWrapper` interface. This feature allows you to wrap any of the processors in the compiled topology, including both custom processor implementations and those created by Streams for DSL operators. This can be useful for logging or tracing implementations since it allows access to the otherwise-hidden processor context for DSL operators, and also allows for injecting additional debugging information to an entire application topology with just a single config.