Delivered stream records on Workflow Tasks and on replay.

[moetemp]

This PR delivers stream records on Workflow Tasks and re-supplies them on replay.

What changed?

• recordworkflowtaskstarted/stream_slices.go stages a range per subscription and reads it from an owned stream or, through the routed client, a standalone one. Slices ride RecordWorkflowTaskStarted and the poll response. A duplicate request gets the same slice. Speculative tasks get no range, since a discarded one commits no cursor.
• The task records only the range it consumed, on WorkflowTaskCompleted. The cursor advance is folded in as that event is built, so both commit together. A subscription with offsets left schedules a task on transaction close, which also covers a fresh subscription to a full stream.
• Replay walks every page of the history it sends and re-reads each range. A range that's truncated, deleted or past stream.replayMaxRecords, stream.replayMaxBytes or stream.replayMaxPages fails the task with STREAM_RANGE_UNAVAILABLE. The second failure in a row terminates the workflow, since one retry covers a moving shard and a second isn't a race. There's no paged re-supply and no short flag on the wire yet, as chasm/lib/stream/doc.go notes.
• All routed reads of one task start share stream.RoutedSetBudget, the deadline the completion path uses, because the execution's lock is held across them.
• GetStreamReplaySlices lets matching re-supply a non-sticky query task, which skips RecordWorkflowTaskStarted. Matching calls it only when GetMutableStateResponse says consumes_streams, so other queries take no history lease. attachReplaySlices returns early on a sticky task, so an SDK that refetches history after eviction gets no slices.
• tests/testcore/onebox.go starts more than one history host for the cross-host test. tests/sdk_server_host_test.go and tests/stream_publish_cost_test.go are opt-in. TestARefusedTruncateProbesThePinsItWasRefusedFor tests a Added the stream service and its frontend wiring. #5 change. It lands here with the consumer harness it needs.

Part of AI-198 (epic AI-37).

Why?

This is the half of the design that has to hold under replay. A cold worker sees what the original execution saw, and History never holds a payload.

How did you test it?

go build ./..., make proto and make fmt are clean. Unit tests ran for ./chasm/lib/..., ./service/history/..., ./service/matching/ and ./common/.... The functional tests ran with -tags test_dep: delivery, continue-as-new, replay past the first page, a deleted stream, the query path, cross-host routing and speculative tasks.

• Unit Tests
• Staging
• End to End Tests

[moetemp]

Replaced by #18, #19, #20, #21, #22, #23, #24, #25, #26, #27, #28, #29, #30, #31, #32, #33, #34, #35, #36 and #37.

Same content, split into 20 PRs in the v3 series: the notification channel first, then the streaming interface, then native streams and the rest. The branch stays as a pin.