[Jetty] Added the Workflow wake target with rechecks and pruning.

[moetemp]

What changed?

This PR adds the Workflow wake target. A Workflow reader attaches with workflow_target, and the notifier wakes it through History.

• The stream_wake callback variant sends progress to History RecordStreamWake. Its completion is the close, a resubscribe after an idle timeout, or nothing after a detach.
• An attach reserves the reader's place first, so an attach past history.maximumStreamWakeSources readers at once, or to a closed run, fails. A detach, a failed attach, and a taken close or resubscribe wake free the place.
• A close wake carries no close result, and a close failure only up to 4 KiB, since one scheduled event carries the wakes of all of a run's readers. The reader's final read returns the outcome from the store.
• A delivery that finds the run closed marks the callback, and the notifier drops it from its limits (JD-6).
• After streamnotifier.recheckInitial (1 min) of quiet the notifier sends a recheck wake, doubling up to streamnotifier.recheckMax (1 h). A notification resets the gap.
• Progress deliveries are numbered, so a recheck at an old counter, or zero, goes out.
• streamnotifier.ownerCheckInterval drops from 5 min to 30 s. An implicit close then reaches waiting callbacks within about 30 s plus the grace, at one owner describe per interval per notifier with callbacks.

Why?

A Signal would add an event and an Action per wake (JD-5). Rechecks close the crash gap without a Redis outbox (JD-10). Dead callbacks must not fill the 2,000 limit (JD-6). With Ford gone, the owner check is the only implicit close (JD-9).

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

Unit tests in chasm/lib/callback and chasm/lib/streamnotifier (TestWorkflowTargets, TestRechecks), and the functional TestStreamWakeSuite end to end through the notifier.