Session Replay gesture batching measures durations with the wall clock #6523

Split from #6522. These two pieces measure how long something took, so they can move to a Stopwatch before v9. Check-in durations did the same in #6032. The gesture timestamps (when something happened) stay on the wall clock and are part of #6522, which waits for v9.

What reads the wall clock

While a finger moves, ReplayGestureConverter batches touch positions and sends them as one move event every 500ms. Two things there subtract one wall-clock reading from another:

• Batch timer. The batch is sent once now - touchMoveBaseline passes 500ms. This only decides when to send, so nothing in the payload changes. It's the sibling of the 50ms move debounce that fix(replay): Measure recording deadlines on a monotonic clock (JAVA-575) #6090 moved to a Deadline.
• timeOffset. Each position records how long after the batch started it happened, always under about 500ms. It is sent to Sentry, but it's a duration, not a timestamp.

What goes wrong

If the clock steps backward during a swipe, now - touchMoveBaseline goes negative. The batch isn't sent until the clock catches back up, and if the finger lifts first, the batched positions are dropped. A forward step sends the batch at once, with offsets stretched by the size of the step.

Not a breaking change

With no clock step, the values are the same as today. It doesn't touch session counts, the public API or a critical customer metric.

Done when

• The batch timer and timeOffset come from one Stopwatch, started when a batch begins, on the ticker the converter already takes.
• Event timestamps (touch start, end and cancel, and the move event's timestamp) still use dateProvider. Those move in Session Replay segment, buffer and gesture timestamps read the wall clock #6522.
• Tests cover a backward and a forward clock step during a swipe.