merge: #10072

10072: Document ProcessingScheduleService.runAtFixedRate r=pihme a=korthout

## Description

<!-- Please explain the changes you made here. -->
The ProcessingScheduleService has a runAtFixedRate which is implemented in a simple way: run the task after a delay and then schedule itself. But there are some quirks around this that should be clear to the caller.

Specifically, that there is an initial delay before the task is run, **and** that due to the way it reschedules the task, time traveling only affects the currently scheduled delay.

## Related issues

<!-- Which issues are closed by this PR or are related -->

related to #10064 



Co-authored-by: Nico Korthout <nico.korthout@camunda.com>

engine/src/main/java/io/camunda/zeebe/engine/api/ProcessingScheduleService.java

@@ -17,6 +17,18 @@ public interface ProcessingScheduleService {
 
   <T> void runOnCompletion(ActorFuture<T> precedingTask, BiConsumer<T, Throwable> followUpTask);
 
+  /**
+   * Schedule a task to execute at a fixed rate. After an initial delay, the task is executed. Once
+   * the task is executed, it is rescheduled with the same delay again.
+   *
+   * <p>Note that time-traveling in tests only affects the delay of the currently scheduled next
+   * task and not any of the iterations after. This is because the next task is scheduled with the
+   * delay counted from the new time (i.e. the time after time traveling + task execution duration +
+   * delay duration = scheduled time of the next task).
+   *
+   * @param delay The delay to wait initially and between each run
+   * @param task The task to execute at the fixed rate
+   */
   default void runAtFixedRate(final Duration delay, final Runnable task) {
     runDelayed(
         delay,