[Jetty] Folded stream wakes onto the next Workflow Task scheduled event.

[moetemp]

What changed?

This PR adds the wake fold. History keeps the latest wake of each stream reader of a Workflow run and puts it on the next Workflow Task scheduled event as stream_wakes, with no event of its own.

• History RecordStreamWake(namespace_id, execution, wake) keeps the wake on the CHASM Workflow (StreamWakes). A closed run answers NotFound.
• A wake schedules a task when none is pending. A wake on a scheduled, unstarted task folds into it and gets one follow-up task.
• Tasks that only wakes schedule wait streamwake.minInterval (1 s) after the last one.
• A task a Local Activity heartbeat forced carries no wake, nor do its retries. After a failover converts a retry, the wake waits for the next task.
• history.maximumStreamWakeSources (32) bounds the readers per run. One more gets FailedPrecondition.
• The task rules are generic over a key (TaskCarriedIndex, taskCarrier), so Bridge can put its Nexus progress on them.

It carries the generic half of moetemp/temporal#39. The Nexus keying stays in Bridge.

Why?

Wakes ride the scheduled event, keyed by reader, so a burst costs one task and replay sees what the Workflow saw (JD-7). The rules follow DD-34, DD-52, DD-55, DD-74 and DD-83.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

stream_wakes_test.go, TestStreamWakesAcrossFailoverConversion, and the functional TestStreamWakeSuite.