Let a workflow subscribe to a stream and append records to it.

[moedash]

This PR lets a workflow subscribe to a server-side stream and append records to one.

What changed?

• SubscribeStream and AppendStreamRecords on the lang command message at 29 and 30. The external family takes 23 to 28, so both trees encode the native commands at the same numbers.
• The lang fields match the wire: stream_name on an append, stream_name_or_id and start_position on a subscribe. The From conversion passes the position through untouched.
• Two command machines, append_stream_records_state_machine.rs and subscribe_stream_state_machine.rs. Neither resolves. A subscription's ranges arrive later as their own jobs, and that's Delivered server-side stream ranges to workflows. #7.
• Record bodies travel on the command. History gets one fixed-size event naming the offset range, so batch size doesn't grow History.
• A reissued command is held against its recorded event. An append matches on stream and record count, and an unnamed append on the stream the run's earlier unnamed appends resolved to. A subscribe matches on its stream only.
• Both machines are registered with the transition coverage reporter, and the unreachable adapt_response arms say fatal!.
• SubscribeNotificationChannel on the lang command message at 31 and NotificationsReceived on the activation job at 22. subscribe_notification_channel_state_machine.rs holds a reissued subscribe to its recorded event by channel, and the Rust SDKs ignore the job since they cannot subscribe and a notification carries no data.
• UnsubscribeNotificationChannel is still refused on this layer. Its machine lands with Delivered server-side stream ranges to workflows. #7, next to the delivery it is paired with.

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

Why?

Both are ordinary commands with a history event, so they fit the command matching replay relies on. The server resolves a subscription's addressing and start, since the workflow can't look them up without I/O, so the replay check doesn't compare the recorded start offset. A subscription made through the stream service leaves no event, so history can't tell a run's first subscribe, and a test pins that non-check.

How did you test it?

cargo check --workspace, cargo test -p temporalio-sdk-core --lib core_tests::streams, cargo fmt --all --check and cargo test-lint. The stream tests cover both commands reaching the server as lang asked, each start position arm, both round-tripping through replay, and a reissue to another stream or with another batch size failing the task.

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