Wait node reverts to in-memory execution for short waits

The Wait node in n8n workflows is getting a simplification. Waits under 65 seconds will again execute in-memory using JavaScript's setTimeout, rather than going through the database server clock synchronization that was introduced earlier this year.

The previous approach attempted to make the Wait node "fully durable" by anchoring all scheduling decisions to the database server's clock — this required a 5-second poll interval, a 15-second lookahead window, and NTP-style compensation for query round-trip time. The complexity proved unnecessary.

Now, waits shorter than 65 seconds resolve immediately within the executing process. Longer waits still write to the database, but the polling interval returns to 60 seconds using the local server's clock. The ClockRepository and DbClock service that provided DB time access have been removed entirely, along with the associated Prometheus gauge for clock skew monitoring.

This reverts a significant chunk of infrastructure — over 450 lines across five files were deleted. The trade-off favors simplicity: the local clock is good enough for workflow scheduling, and removing the sync layer eliminates potential failure points.