Added workflow.stream_reader and workflow.stream_writer.

[moedash]

This PR lets workflow code read and write a stream through whatever provider the worker has.

What changed?

• workflow.stream_reader() and workflow.stream_writer(), with StreamReader and StreamWriter. They default to the default topic, and a reader can start at END or at the last N records.
• The worker takes the provider from its own config or from the client's, and hands it to each workflow instance and to the replayer.
• A lifecycle interceptor runs the provider's start hook on the workflow's own event loop, after the workflow's __init__ and before the first task's Signals and Updates are handled. A provider that serves outside readers through handlers needs them in place for an Update that arrives with the first task. The finish hook runs on return, failure, cancellation and continue-as-new, but not on eviction.

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

Why?

A workflow shouldn't have to know which store holds its stream. With the provider on the worker, the same workflow code runs on memory, Workflow Streams or a server-side stream. The hook placement used to live in the Workflow Streams provider. It's runtime behaviour every provider relies on, so it moves here, where both Python chains share it.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

poe lint is clean. The hook, reader and workflow stream tests pass against the memory provider on the dev server the fixtures start. The workflow, replayer and interceptor suites still pass.