Fixes #6019

WorkerService::atTime() was scheduling timers using kj::Timer::afterDelay(delay), which internally computes the target time as timer.now() + delay. However, kj::Timer::now() only updates when the event loop polls for I/O — it stays frozen while JavaScript is executing. If significant CPU time elapsed since the last poll (e.g. compiling and running a script before the first setTimeout), timer.now() would be stale by that amount, causing afterDelay() to schedule the timer at a target time that was effectively in the past relative to the real monotonic clock. This made the first setTimeout(fn, 100) resolve in as little as 1ms of wall-clock time, while subsequent calls (which ran after the event loop had polled and refreshed the timer) worked correctly.