Clients can influence RNG output by calling reducers at specified times

Because ReducerContext.rng() is "seeded by the timestamp of the reducer call" clients can send the call at a specified time to influence the RNG output.

While we cannot hit a specified µs which would give us 100% control we can still hit bigger timing windows. They have a chance of being more "lucky" due to RNG output not being perfectly uniform over time. (as an example for coin toss it's perfectly reasonable to get a few heads in a row).

Here's an example table of attack window vs waiting time for a reducer rolling true with 10% probability:

#[spacetimedb::reducer]
pub fn rand(ctx: &ReducerContext) {
    let mut rng = ctx.rng();
    let result = rng.gen_ratio(1, 10);
    ctx.db.rng_results().insert(RngResult {
        id: 0,
        result,
    });
}

From my tests in real-world scenarios it's reasonable to hit a 500µs-2ms window.

Results for attacking a reducer rolling true 10% of the time hosted on Maincloud from a host in phoenixNAP Ashburn DC: ATTACK_RESULTS: 1379 / 10000 (10% -> 13.7900%)

Longer writeup: https://koz.omg.lol/2025/10/spacetimedb-rng-manipulation-attack

Start by reading the ReducerContext.rng() entry point and the reducer example in the issue, then reproduce the timing attack described in the writeup. Done means reducer callers can no longer improve RNG outcomes by choosing when to invoke the reducer, with coverage for the reported attack scenario.