Added the stream accessors for activities and clients.

[moedash]

This PR lets activities and clients reach a stream the same way workflow code does.

What changed?

• activity.stream_handle() and Client.get_stream_handle() open a stream by StreamRef or by topic. Typed topics work on every call.
• Client.create_stream(stream_id, ...) creates a standalone stream with a retention policy, and its handle's close() seals it.
• StreamRef names workflow-owned, activity-owned and standalone streams. The memory provider hosts all three.
• stream_channel(ref) names the notification channel a stream notifies, derived the way the server derives it. A listener needs no lookup.
• The changelog entry for the stream interface.

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

Why?

A stream is useless if only its owning workflow can touch it. Activities produce into streams, and clients read them to show progress. A ref is plain data, so a stream can be handed to another process. stream_channel sits here because it maps a ref to an address, and the Nexus consumer uses it later as its default.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

poe lint is clean. The accessor, activity-stream, standalone conformance and stream_channel cases pass on the memory provider, with the dev server the fixtures start.