Added the generated Go for the stream commands and events.

[moetemp]

This PR adds the generated Go for the stream and notification channel protos from api #1.

What changed?

• proto/api points at a fixed commit of the api branch, the execution addressing on top of the unsubscribe command, not at the branch tip. A later push there can't change what make proto emits. .gitmodules keeps the fork URL until the api change lands upstream.
• The generated packages cover StreamRecord, StreamSlice, the two stream commands, the appended event, StreamRange, StreamStartPosition and the five new failure causes.
• The notification channel brings the notification/v1 package with Notification, ChannelListener and ChannelKind, the NotifyChannel, RegisterChannelListener, UnregisterChannelListener, PollChannel and DescribeChannel RPCs with their gateway routes in service.pb.gw.go for the independent, workflow and activity bindings, their methods in proxy/service.go and their mocks in workflowservicemock, the subscribe command and event, and WorkflowTaskScheduledEventAttributes.notifications. The five requests carry the optional execution, a common.v1.Execution, and the describe response carries kind and linked_to as the same type.
• UnsubscribeNotificationChannelCommandAttributes, WorkflowNotificationChannelUnsubscribedEventAttributes, their Command and HistoryEvent arms and the CommandType, EventType and WorkflowTaskFailedCause values are generated with their helpers. Neither message carries a payload, so the visitor has no case for them.
• DescribeWorkflowExecutionResponse.channel_subscriptions and workflow/v1.ChannelSubscriptionInfo are generated with their helpers, and the payload visitor walks the list into pending_notification, so a codec reaches the held notification's metadata on DescribeWorkflowExecution too.
• temporalproto/openapi is regenerated from the api branch's OpenAPI specs.
• The generated payload visitor in proxy/interceptor.go walks the two messages that carry a StreamRecord, AppendStreamRecordsCommandAttributes.records and PollWorkflowTaskQueueResponse.stream_slices, and walks Notification.metadata through the existing payload-map case, so a codec reaches it on the notify request, the poll and describe responses and the scheduled event. A start position carries no payload, so the visitor skips it.
• proxy/interceptor_test.go counts the two Payload fields that AppendStreamRecordsCommandAttributes reaches: a record's body and its metadata values. These counts are the only hand-written change.

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

Why?

The server pins go.temporal.io/api at this head, so this is the Go half of api #1. The payload visitor lets a codec proxy reach record bodies and metadata on both paths this API owns.

How did you test it?

CI runs make check test. It regenerates from the pinned submodule, fails on a diff, and runs the suite with the payload-walker test. It passes at the head. nexus-rpc-gen isn't installed locally, so service_nexus.pb.go comes from the tree as is, and the Nexus yaml doesn't change. The server's functional tests run against this module in the temporal PRs of the series.

• Unit Tests
• Staging
• End to End Tests

[moetemp]

Replaced by #2, #3, #4 and #5.

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