Enable MD009 trailing whitespace linting and fix violations

Enable the MD009 markdownlint rule which detects trailing whitespace
at the end of lines. Fix all existing violations across the codebase.

Auto-generated files (Changelog/*, Librdkafka/*) are excluded from
linting and left unchanged.

Author: mensfeld

.markdownlint-cli2.jsonc

@@ -20,7 +20,6 @@
   ],
   "config": {
     "default": true,
-    "MD009": false,
     "MD025": true,
     "MD029": {
       "style": "one_or_ordered"

Admin/API.md

@@ -336,7 +336,7 @@ end
 #     Partition: 2, Offset: 181414, Lag: 5
 #     Partition: 3, Offset: 181070, Lag: 8
 #     Partition: 4, Offset: 180974, Lag: 4
-# 
+#
 # Consumer group: karafka_web
 #   Topic: karafka_consumers_reports
 #     Partition: 0, Offset: 48669, Lag: 2
@@ -372,7 +372,7 @@ end
 #     Partition: 2, Offset: 181511, Lag: 11
 #     Partition: 3, Offset: 181163, Lag: 3
 #     Partition: 4, Offset: 181075, Lag: 14
-# 
+#
 # Consumer group: karafka_web
 #   Topic: karafka_consumers_reports
 #     Partition: 0, Offset: 48689, Lag: 3

Advanced/Broker-Failures-and-Fault-Tolerance.md

@@ -430,7 +430,7 @@ Alert on these conditions:
 Karafka **is designed** to handle Kafka broker failures gracefully. During maintenance operations and unexpected outages:
 
 - **Messages will continue to be consumed** (from available brokers)
-- **Producers will queue messages** until brokers are available  
+- **Producers will queue messages** until brokers are available
 - **Automatic reconnection** handles broker transitions
 - **Connection refused errors** are expected and normal
 - **Recovery typically occurs within 1-15 seconds** of broker restoration

Advanced/Debugging.md

@@ -213,7 +213,7 @@ class KarafkaApp < Karafka::App
       # this will start processing from beginning each time new
       # karafka process starts
       consumer_group "app_group_#{Process.pid}" do
-        topic :orders do 
+        topic :orders do
           consumer OrdersConsumer
         end
       end

Advanced/Declarative-Topics.md

@@ -180,7 +180,7 @@ With this setting enabled, Karafka will fail to start if any topics in the routi
 
 ## Detailed Exit Codes
 
-When managing Kafka topics via Karafka's CLI commands, the `--detailed-exitcode` option can be configured. This option alters the exit codes based on the operation's result. This option provides more granular information, making integrating Karafka's topic management into automated systems like CI/CD pipelines easier. 
+When managing Kafka topics via Karafka's CLI commands, the `--detailed-exitcode` option can be configured. This option alters the exit codes based on the operation's result. This option provides more granular information, making integrating Karafka's topic management into automated systems like CI/CD pipelines easier.
 
 When the `--detailed-exitcode` flag is enabled, the `topic` related commands exit codes will work as follows:
 

Advanced/Embedding.md

@@ -25,7 +25,7 @@ In a cluster mode:
 **For Puma < 7:**
 
 ```ruby
-# config/puma.rb 
+# config/puma.rb
 
 workers 2
 threads 1, 3
@@ -44,7 +44,7 @@ end
 **For Puma >= 7:**
 
 ```ruby
-# config/puma.rb 
+# config/puma.rb
 
 workers 2
 threads 1, 3
@@ -65,7 +65,7 @@ In a single node mode:
 **For Puma < 7:**
 
 ```ruby
-# config/puma.rb 
+# config/puma.rb
 
 preload_app!
 
@@ -82,7 +82,7 @@ end
 **For Puma >= 7:**
 
 ```ruby
-# config/puma.rb 
+# config/puma.rb
 
 preload_app!
 
@@ -153,7 +153,7 @@ Before you initiate the embedded Karafka server, your application code must be p
 
 ### Critical Error Handling
 
-When operating Karafka in Embedded mode, it's crucial to understand that certain critical errors might be silently overlooked if the supervising process for Karafka Embedding does not correctly signal those errors. While Karafka might recognize and attempt to raise an error and notify about it via its instrumentation pipeline, the supervising process might not propagate or report this, leading to potential silent failures or unnoticed issues. For robust and reliable production deployments, it's critical to ensure that any errors Karafka might produce are not only correctly signaled by the supervising process but also reported and monitored. 
+When operating Karafka in Embedded mode, it's crucial to understand that certain critical errors might be silently overlooked if the supervising process for Karafka Embedding does not correctly signal those errors. While Karafka might recognize and attempt to raise an error and notify about it via its instrumentation pipeline, the supervising process might not propagate or report this, leading to potential silent failures or unnoticed issues. For robust and reliable production deployments, it's critical to ensure that any errors Karafka might produce are not only correctly signaled by the supervising process but also reported and monitored.
 
 ### Partial/Silent Crashes
 
@@ -241,7 +241,7 @@ end
 ```
 
 ```ruby
-# Sidekiq configuration  
+# Sidekiq configuration
 Sidekiq.configure_server do |config|
   config.on(:startup) do
     Karafka.setup do |config|

Advanced/Inline-Insights.md

@@ -50,7 +50,7 @@ class LogEventsConsumer < ApplicationConsumer
     # Buffering decisions are made based on current lag and buffer size.
     return if current_lag > LAG_THRESHOLD && @buffer.size < FLUSH_SIZE
 
-    @buffer.flush 
+    @buffer.flush
     mark_as_consumed(messages.last)
   end
 

Advanced/Latency-and-Throughput.md

@@ -97,7 +97,7 @@ The `request.required.acks` parameter determines the number of acknowledgments t
 
 - **0 (No Acknowledgement)**: The broker does not respond to the producer, and the message is considered delivered the moment it is dispatched. This setting provides the lowest latency since the producer doesn't wait for acknowledgments. It's highly performant, allowing for rapid message dispatch, but it risks data loss because there's no confirmation that the broker received the message. Suitable for non-critical data where speed is crucial.
 
-- **1 (Leader Acknowledgement)**: The leader broker responds once it has written the message to its log. This setting balances latency and durability, providing a quick acknowledgment while ensuring the leader broker logs the message. It offers a good trade-off for most use cases, ensuring reasonable reliability with moderate latency. 
+- **1 (Leader Acknowledgement)**: The leader broker responds once it has written the message to its log. This setting balances latency and durability, providing a quick acknowledgment while ensuring the leader broker logs the message. It offers a good trade-off for most use cases, ensuring reasonable reliability with moderate latency.
 
 - **-1 or all (All ISR Acknowledgements)**: The leader broker waits until all in-sync replicas have acknowledged the message. This setting ensures maximum durability, minimizing the risk of data loss as the message is replicated across multiple brokers. However, it results in higher latency and reduced throughput. It is best for critical applications where data integrity is essential.
 
@@ -155,7 +155,7 @@ end
 
 ### Asynchronous Producing
 
-Asynchronous dispatch reduces waiting time for acknowledgments, allowing your application to continue processing tasks immediately. This significantly lowers end-to-end latency within your application and increases WaterDrop throughput. 
+Asynchronous dispatch reduces waiting time for acknowledgments, allowing your application to continue processing tasks immediately. This significantly lowers end-to-end latency within your application and increases WaterDrop throughput.
 
 Asynchronous producing is the recommended way for any non-critical messages.
 

Advanced/Multi-Cluster-Setup.md

@@ -1,6 +1,6 @@
 # Multi-Cluster Setup
 
-Karafka is a robust framework that allows applications to interact with multiple Kafka clusters simultaneously. This provides enhanced scalability, redundancy, and flexibility, enabling developers to optimize data processing and manage message streams across various clusters with ease. 
+Karafka is a robust framework that allows applications to interact with multiple Kafka clusters simultaneously. This provides enhanced scalability, redundancy, and flexibility, enabling developers to optimize data processing and manage message streams across various clusters with ease.
 
 ## Overview
 

Advanced/Offset-management.md

@@ -63,7 +63,7 @@ def consume
 end
 ```
 
-Karafka offers two additional methods to commit already stored but not committed offsets to Kafka: `#commit_offsets` and `#commit_offsets!`. 
+Karafka offers two additional methods to commit already stored but not committed offsets to Kafka: `#commit_offsets` and `#commit_offsets!`.
 
 These two methods allow you to manage your consumer's offsets, ensuring Kafka knows the last message your consumer has processed.