[moetemp]

What was changed

This PR adds the streams cargo feature to the bridge, which links the Stream runtime crates and builds a runtime for the Redis and memory backends. temporalio-streams has the runtime and the memory Store, and temporalio-streams-redis has the Redis Store.

• The feature is off by default and on in poe build-develop and every wheel build. fips turns it on too.
• StreamCallError is in every build, so Python can import it with the feature off.
• temporalio-streams comes from the Core submodule. [patch.crates-io] points the Redis crate's temporalio-common and temporalio-streams at the submodule, so the bridge sees one copy of each type.
• The TLS and fips features forward to the Redis crate, which links the Redis client.
• The linters skip the submodule, since it has the crate's Python script of the shared vectors.
• Fork-only pins. The submodule is at 86b1ee18 on moetemp/sdk-rust, the Stream crate of feat: add the temporalio-streams crate with the Stream protos temporalio/sdk-rust#1733 and its writers on top of the merged feat(brook): add the dispatching Workflow Task to each Local Activity start temporalio/sdk-rust#1703. Its wire has the StreamRef, a oneof Producer epoch, a strict create with a request id, and a close that writes no Record. Cargo.toml takes temporalio-streams-redis by git from temporal-community/sdk-streams at 6500b21d, and Cargo fetches it with the feature off too. Upstream pins the merged Core commit, takes the Redis crate from crates.io by version, keeps the patch and drops the git source.

Why?

The Stream runtime is Rust, so every SDK shares the Store logic and its rules. A Python build links it like the rest of Core.

Open question. With the feature off by default, a source build from the sdist has no Stream runtime, but the wheels have it. Should it be on by default once the crate is on crates.io?

Part of the Streams review series.

Checklist

1. How was this tested:
   • poe lint, cargo clippy and cargo fmt on both feature sets, and pytest tests/bridge.