Held an activity's own streams on the Redis provider.

[moedash]

This PR lets an activity own streams on the Redis provider.

What changed?

• RedisStreams.get_activity_stream_handle() returns a real handle instead of refusing.
• An activity's topics live in their own Redis streams, keyed by the run its execution belongs to and the activity id. A retry writes to the same stream, and an id started again in a new run starts new ones.
• A read ends once the activity is terminal and the retained tail is delivered. A standalone activity is described directly. A workflow's activity is described through its workflow.
• The shared activity suite runs on Redis under STREAMS_LIVE=redis, and the Redis module covers the key scheme and run keying.

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

Why?

The interface lets an activity write its own stream, and the server-side provider already keys those by run. An activity's append is visible as soon as Redis takes it. There's no workflow reading it, so there's no staging. The owner sits in one key component joined with /, a character the chain keys never contain, so an activity's key can't collide with a workflow's.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

poe lint is clean. The streams suite with STREAMS_LIVE=redis, which now includes the activity cases, passes against a channel server and a local Redis.