Pinned Core to the stream head and added the stream client.

[moedash]

This PR pins Core to the stream head and adds a client for the server's stream service.

What changed?

• temporalio/bridge/sdk-core pins the moe/AI-198-core-3-delivery head. It carries the stream activation job, the subscribe_stream and append_stream_records commands, the subscribe start position, and the notification channel: the SubscribeNotificationChannel and UnsubscribeNotificationChannel command machines and the NotificationsReceived job folded from the task's scheduled events, with each notification's linked_to carried through as the server sent it, a common.v1.Execution naming a workflow or a standalone activity. The live workflow channel cases from Added the workflow-side stream reader and writer. #12, the unsubscribe one included, run from this layer, since the Core below it only carries the protos.
• The bridge protos, temporalio/bridge/_visitor.py and the Nexus system API are regenerated from that pin. The payload visitor reaches each record's body and metadata.
• temporalio/api/streamservice/v1/ holds the vendored stream service protos. scripts/gen_stream_protos.py builds them from a server checkout with a protobuf 3 protoc, and mypy-protobuf writes the stubs. The script rewrites the stubs' temporal.api.* type references onto temporalio.
• temporalio/client_stream.py holds StreamClient, StreamHandle and WorkflowStreamHandle over describe, append and poll. A failure surfaces as StreamNotFoundError, StreamProducerError or RPCError, never as a grpc type. The producer conflict is recognised under the FAILED_PRECONDITION the server sends with its reason token, and under the INVALID_ARGUMENT a server built before the tokens sent.
• A record crosses between StreamRecord and the stored shape by descriptor. A field with no counterpart on the other side raises.
• StreamClient.activity_stream() opens a stream an activity owns. A first read takes start=, and a standalone handle has truncate().

This layer wires nothing into a workflow or a provider. #9 adds the provider and #14 adds replay.

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

Why?

sdk-core doesn't know the stream service, so the client opens its own grpcio channel. On this layer that channel is plaintext, and #9 builds it from the client's connection. The pin, the generated code and the client sit together so the next two layers are Python a reviewer can read without a rebuild.

How did you test it?

uv run poe build-develop, then ruff check --select I, ruff format --check, mypy, pyright, basedpyright and pydocstyle on a cold .mypy_cache, where the stub rewrite bug shows. tests/test_client_stream_records.py and tests/test_client_stream_owner.py run without a server. tests/test_client_stream.py runs live with TEMPORAL_STREAM_TARGET on a server from the moedash/temporal chain. It covers append, poll, describe, the deduplicated repeat, the long poll, both producer refusals and start positions on a truncated stream. The channel cases from #12, the workflow one included, passed against that server with -E host:port. TLS and API keys come with #9.

• Unit Tests
• Staging
• End to End Tests

[moedash]

Replaced by #19, #20, #21, #22, #23, #24, #25, #26, #27, #28, #29, #30, #31, #32, #33, #34, #35, #36, #37, #38, #39, #40, #41, #42, #43, #44, #45, #46, #47, #48, #49, #50, #51, #52, #53, #54 and #55.

Same content, split into 37 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.