Clarify multi-bucket ratelimit decision logic

docs/modules/ratelimit.md

@@ -126,6 +126,8 @@ The **token bucket** algorithm operates as follows:
 1. **Checking phase**: During this phase, tokens are incrementally added to the specified bucket at a constant rate. If the bucket is full, incoming tokens are discarded. When a message arrives, Rspamd checks if the message can acquire a token from the designated rate bucket, and if there are sufficient tokens, the message is processed immediately; otherwise, the it is temporarily deferred (leading to a soft reject action).
 2. **Bucket state update**: After a message has been processed, whether delivered or rejected, Rspamd updates the bucket's state, removing a token per processed message. This phase also includes the adjustment of dynamic multipliers to adapt to varying traffic patterns.
 
+When multiple buckets are defined for a single rate limit, each bucket is evaluated independently. A message is rate-limited if **any** of the buckets has insufficient tokens — meaning the message must pass **all** buckets to be accepted. This allows combining different constraints: for example, a bucket with a high burst capacity but low rate to limit sustained throughput, alongside a bucket with a low burst capacity but high rate to cap sudden spikes.
+
 Before version 3.9.0, the dynamic rate-limit feature was enabled by default. Starting from version 3.9.0, this feature is disabled by default and requires explicit activation in the configuration. Alternatively, you can configure the `ham_factor_rate`/`spam_factor_rate` and/or `ham_factor_burst`/`spam_factor_burst` multipliers for individual buckets as needed.
 
 To better illustrate the concept of dynamic multipliers, refer to the sample graph below. It demonstrates how the burst multiplier varies depending on the number of received ham messages (x > 0) and spam messages (x < 0):