Scheduled reducer: use timestamp from reducer params for next run

[Shubham8287]

Description of Changes

We are scheduling using Timestamp::now() instead of last run timestamp. It causes any interval reducer which has non-negligible execution time to gradually drift.

I fixed it once back :| - #3657.

API and ABI breaking changes

NA

Expected complexity level and risk

1

Testing

I want to add a test for it, but I don't know how to add non-flaky test for it.

[sephirith]

Please deploy this in 2.7.0 Especially if it is a regression.

[cloutiertyler]

I want to add a test for it, but I don't know how to add non-flaky test for it.

@Shubham8287 maybe a use case for DST?

[bfops]

Please deploy this in 2.7.0 Especially if it is a regression.

The 2.7.0 release is already cut and tested, so this will likely not make it in. We may decide to do a patch release, but otherwise this will make it in to next week's release instead.

[bfops]

This was codex's suggestion for at least being able to unit test. unsure if it's sane. The proposed refactoring sounds reasonable for making it harder to reintroduce this bug.

  ## Summary

  Add a deterministic unit test for interval rescheduling, backed by a type-level guard that prevents the successful reducer path from discarding its original scheduled time. Do not use sleeps or elapsed wall-clock tolerances.

  ## Implementation Changes

  - Extract the Reschedule calculation into a pure helper taking ScheduleAt and the original (Timestamp, Instant).
  - Make call_scheduled_reducer_with_tx require that tuple rather than accepting Option; it is available for both queued and volatile reducer calls.
  - Keep the “use current time” fallback only for cleanup/error paths where no call timestamp was resolved.
  - No public API changes.

  ## Test Plan

  - Add a unit test in scheduler.rs with fixed timestamps, an arbitrary Instant baseline, and a known interval.
  - Simulate completion occurring much later without actually waiting.
  - Assert:
      - at_ts == previous_scheduled_timestamp + interval;
      - at_real == previous_scheduled_instant + interval;
      - neither result is based on the simulated completion time.

  - Optionally verify a one-shot ScheduleAt::Time produces no interval reschedule.
  - Run cargo nextest run -p spacetimedb-core interval_reschedules_from_previous_scheduled_time, followed by the relevant core test suite.

[gefjon]

I'm creating a follow-up ticket in #5591 to test this. Let's merge and release ASAP to fix the bug for our users.