Carried the external stream task and replay wake fixes.

[moedash]

This PR fixes the external stream task lifetime and replay wakes, and resumes parked external stream waits from channel notifications.

What changed?

• Cache zero: a retained external stream task stays until its normal boundary, as a local activity does. See retains_task_for_external_streams in managed_run.rs and the eviction check in workflow_stream.rs.
• Replay wakes: a wake Signal that replay reaches inside a History page resumes the reconstructed waits before the task reports empty.
• Output replacement: a stale wait from an earlier task doesn't force an empty replacement task. A completion that stages a commit with output still buffered does force one. The one-outstanding-activation rule logs through dbg_panic! in release builds too.
• Notification receipt: the channel notifications on a task's scheduled event reach lang as one NotificationsReceived job, folded per channel with the highest counter kept, and resume parked waits the way an unparked wake Signal does. The Signal stays as the fallback transport.
• Deferred subscribe: lang reports the channels a run listens on with WorkflowStreamChannels, and Core issues SubscribeNotificationChannel for a new channel on the completion that ends the Workflow Task, after the marker and never on a run-ending one, with the same deferral on replay. The task that opens the first reader stays retained and parks as before.
• Unsubscribe: the UnsubscribeNotificationChannel command variant and its machine, matched against WorkflowNotificationChannelUnsubscribed on replay the way the subscribe is. Core issues it for a channel that left the reported set, ahead of any subscribe on the same completion, so a run rotating channels frees the slot first.
• Protos and client: the stream and notification protos land in the vendored api tree, including the linked channel contract (Notification.linked_to, ChannelKind, the optional execution on the channel requests, and kind and linked_to on DescribeChannelResponse, all naming the owner as a temporal.api.common.v1.Execution by type and business id), the unsubscribe command, event and failed cause, and ChannelSubscriptionInfo with DescribeWorkflowExecutionResponse.channel_subscriptions. The channel calls (NotifyChannel, RegisterChannelListener, UnregisterChannelListener, PollChannel, DescribeChannel) are on the raw client in crates/client/src/grpc.rs and in the C bridge dispatch.
• Backports: the nexus request-timeout header fix (upstream Tolerate out-of-grammar nexus request-timeout headers temporalio/sdk-rust#1497, authorship kept), two integ test fixes, the per-runner integ timeout, and two WIT declarations matched to upstream.

This layer sits on Max's task/python-sdk-streaming. #3 merges it forward onto current main.

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

Why?

At cache zero the worker evicted the retained task, then spun on empty replacement tasks while unread records sat in the store. A channel notification rides the scheduled event of the task it produces, so a provider wakes a parked workflow without a Signal event. Replay doesn't change, because the read lives in the marker and the notification only decides when the live run looks. The WIT and header fixes keep nexgen codegen and nexus_metrics working against the dev server the Python SDK runs.

How did you test it?

The full cargo suite and cargo test-lint ran on the branch. New tests in core_tests/external_streams.rs cover zero-cache retention, buffered output, the stale wait, a wake Signal reached mid-replay, and the notified scheduled event: it yields the job and resumes a parked wait, a failed task hands its notifications to the retry, and replay yields the same job and resumes the reconstructed waits. For the deferred subscribe: a retained task holds the command until the park or finalization that ends it, a command-carrying completion orders it after the marker, a run-ending one issues none, a later task adds nothing for the same channel, replay reissues it from the same report, and a different channel on replay is nondeterminism. For the unsubscribe: a channel that left the set is unsubscribed on the completion that ends the task, a swap unsubscribes before it subscribes, a run-ending completion issues none, replay reissues it from the same report, and a replay still naming an unsubscribed channel is nondeterminism, plus the machine's own unit and replay cases. moedash/sdk-python#15 pins this head and runs the live Redis provider suite on it. The C bridge entries have no Rust test.

• Unit Tests
• Staging
• End to End Tests

[moedash]

Replaced by #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22 and #23.

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