A rate limit now thins the work, not only the messages

The limit was applied in `apply_outputs`, which the executor reaches after the
item is off the queue — so a subscriber told to publish every 15s still cost a
queue entry, a `cascade_started`, a run record and a walk of everything
reachable from it per inbound message. Seven relay nodes behind one inverter
ran 192 times a minute to publish six.

Two halves, matching the two shapes it takes:

`trigger()` now keeps a value whose every port is inside its window and
journals nothing at all. The window split came out of `_throttled` as a
read-only `_window_split`, so the question is asked the same way in both
places and the exact split is still made once, at claim time.

A cascade carries the names it actually published, and the wave runs only the
nodes something in that set feeds. A node whose triggering inputs were all
held back is completed without running, which frees its own consumers to be
judged the same way — the case where a node re-published 619 messages a minute
off inputs that changed six times. Redeliveries and emissions carry no such
set and still walk everything, since one has a half-finished wave to finish
and the other is the value already being in state.

Skipping a node can make one ready that the scheduling pass has already walked
past, so `submit_ready` runs to a fixpoint. That also closes the same latent
hole on the replay path, where a done-marker skip could strand a join with no
future outstanding to come back for it.

Measured with the new `scripts/bench_engine.py`, 500 messages through the
house's shape: a limited source went from 500 cascades / 3500 node runs /
5009 events to 1 / 7 / 19, publishing the same 8 values; an unlimited source
into limited relays took the node reading them from 500 runs to 1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BpfSinyCBfjuieikyfMPbf

backend/fluksio/flow/executor.py

@@ -387,10 +387,17 @@ class ExecutionService:
                 }
             )
 
+        replay = item.deliveries > 1
         try:
-            pipeline.apply_outputs(node, item.outputs or None)
+            published = pipeline.apply_outputs(node, item.outputs or None)
             pipeline.run_downstream(
-                node, entry_id=item.entry_id, replay=item.deliveries > 1
+                node,
+                entry_id=item.entry_id,
+                replay=replay,
+                # A redelivery has to finish a walk that may be half done, and
+                # an item with no payload is the value already being in state.
+                # Neither can say what changed, so neither filters on it.
+                changed=None if replay or not item.outputs else published,
             )
         finally:
             # Paired, or a cascade that raised — state backend gone, say — is a