Wait for a deadline instead of polling for one

The timer thread promoted due work on a fixed one-second tick, so every
delayed item was 0-1000ms late whatever the load — measured on the house
at 705ms mean on a rollershutter stop, which is 2-4% of a 26-second
travel and accumulates in the position the motor node believes it is at.
It now sleeps to the soonest deadline and is woken when a nearer one is
scheduled, which measures 0.9ms end to end through Redis.

A promoted timer also went to the back of the queue. It goes into a due
lane of its own that `claim` reads first, so work that has waited out a
deadline is not held up by work that is merely queued.

Beside it, in the same code: seeding a message now bumps its version, so
a re-put flow's synchronous nodes no longer wait forever on a value that
is sitting in state; the consumer group drops the consumers of engines
that are gone (138 had accumulated on this installation); and the cast
that closes the long-standing `xclaim` mypy error.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/reference/node-types.md

@@ -155,6 +155,12 @@ Order of operations: rate check → delay → forward. With a `cron` and no inpu
 it emits the current time on each tick; with inputs it emits the last value it
 received.
 
+The engine sleeps until a delay is due rather than polling for it, so a `delay`
+fires within a few milliseconds of its deadline on an idle engine, and a due
+timer is taken off the queue before work that is merely waiting. It is not a
+real-time guarantee: the wait ends on a normal thread, and a node that then
+needs a busy cascade slot waits for one.
+
 !!! note "Not in a batch flow"
 
     A rate limit holds a value back for a timer to release, and a run has no