Added one stream interface with its four providers and the Nexus front.

[moedash]

This PR merges both streaming lineages onto main, so one workflow runs on every provider.

What changed?

This is an aggregate PR, labelled skip-changelog. The content is reviewed in the layers. This PR is the merge resolution, the Core repin and the union conformance run. It merges:

• Replayed a workflow that read a server-side stream. #14, the native chain tip. It carries the interface chain Vendored the stream additions to the public API protos. #10 to Added the stream accessors and tied in the interface head. #13 and the native layers Pinned Core to the stream head and added the stream client. #8 and Added the native provider over one owned stream per topic. #9.
• Added the Nexus front that hides the store behind one endpoint. #5, the Nexus front and the Nexus stream consumer, on Added the Workflow Streams provider over the shipped wire format. #4, the Workflow Streams provider.
• Bound Redis to the stream interface as RedisStreams. #17, the external chain tip, carrying Repaired the external stream base and repinned Core. #15 and Added the stream interface on the repaired external base. #16.
• Shared one time-skipping unlock between concurrent result waiters. #18, which shares one time-skipping unlock between concurrent result() waiters.

What the merge adds of its own:

• temporalio/bridge/sdk-core pins moe/AI-198-core-all, the union Core with the notification channel in both kinds, the unsubscribe command, the external chain's channel report and a linked channel addressed by execution. The api and bridge protos are regenerated from it.
• CHANGELOG.md's unreleased block is rewritten by hand from what the tip exports. Repeated merges had spliced and duplicated bullets.
• The constructor-publish conformance case reads while the worker still polls. Here it also runs on Workflow Streams, which answers reads from the workflow.
• Both lineages lifted the same channel surface, so the merge keeps one copy of each method on the workflow instance. The copy kept is the one that also feeds the external-stream runtime and shares the once-per-channel command with it. The unsubscribe sits next to it and clears that once-per-run set, so a later subscribe reaches the server again.
• Both lineages had grown an address type for a channel and its owner, and both added temporalio.common.Execution for the owner. The client's ChannelAddress(channel, execution) is the one address type, with None for no owner, the main chain's Execution is the one owner type, and the external module re-exports the address. The client's helper that resolves workflow_id= into an Execution is kept once as well.
• One live case consumes a Redis stream from a Nexus operation through the channel the Redis producer notifies itself, next to the memory-store case where the test notifies by hand.

What the union carries from the observability round, each from its layer:

• WorkflowExecutionDescription.channel_subscriptions: the channels a run stands on, read from describe().
• ChannelSubscription.unsubscribe(): records the unsubscribe command and drops the handle before the next task.
• temporalio.client.stream_channel(ref): the channel a native stream notifies on every append and on its close.
• stream_consumer_operation: a Nexus operation that consumes a stream through its channel, with a standalone HTTP host.
• The external reader's channel report, WorkflowStreamChannels: Core subscribes and unsubscribes from it, so no command rides the task that opens a reader.

The notification channel comes in from both chains in its two kinds. An independent channel is addressed by name: a workflow listens with workflow.subscribe_channel(), which issues the subscribe command, and the client's notify_channel, describe_channel, poll_channel and the listener calls address it without a workflow. A channel linked to an execution, a workflow or a standalone activity, is addressed by execution= on the same client calls, a temporalio.common.Execution of a type, a business id and an optional run id, with workflow_id= kept as the short form for a workflow. The owner reads it with workflow.linked_channel(), which issues no command, since the owner is the listener by construction, and a notification carries linked_to as an Execution so the instance routes it to the handle of its kind. The Redis provider notifies the linked channel of a workflow-owned stream and the independent channel of a standalone or activity-owned one, ahead of the Signal, and the Signal stays as the fallback on a server without channels. The live channel cases are gated on a server named with -E, since the dev server the suite starts has neither kind.

Capability split on this head: the memory provider, the native provider and the Redis provider hold activity-owned and standalone streams. Workflow Streams refuses a standalone activity's streams and standalone streams. The Nexus front refuses activity-owned streams. Each refusal is a StreamUnsupportedError.

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

Why?

The swap claim needs one branch where every provider coexists. A workflow file stays the same, and only the provider in Client.connect(plugins=[...]) changes. It looks large against main because it includes both lineages whole.

How did you test it?

poe lint passes. tests/streams runs with STREAMS_LIVE=redis, STREAMS_LIVE=native and STREAMS_LIVE=nexus, in separate runs, against a server from moedash/temporal#15, the layer with the unsubscribe and the channel a native stream notifies. The Redis run was repeated in the server's other switch position, channel.linkedKindEnabled off, where the external-stream and Redis channel suites run on the independent kind and the retention cases run again. The Nexus consumer file runs there with nothing skipped, the native case and the Redis case included. The memory suite and the Signal fallback run on the stock dev server, and the external stream contrib tests pass on a local Redis in both switch positions. One follow-up stays: a pending Nexus operation task is reported at interpreter exit after the consumer file, harmless. tests/worker/test_workflow.py last passed at the previous head, where the suite was stable under --workflow-environment time-skipping with #18 merged. moedash/temporal-agent-harness#2 pins this head, and its four lanes pass. #7 runs the June scenarios on top of it.

• 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.