Reported a workflow's notification channels on describe.

[moetemp]

This PR reports a workflow's notification channels on DescribeWorkflowExecution.

What changed?

• DescribeWorkflowExecutionResponse.channel_subscriptions lists the channels the run stands on: the independent channels it subscribed to and the linked channels that hold any state, sorted by channel name with the independent kind first when a name is in both.
• An independent entry carries the subscribe event id, the highest counter the run accepted, the notification waiting for the next scheduled event, and the counter its scheduled, not yet started task carries. Its listener and retained counts are zero, since they belong to the channel execution.
• A linked entry carries the latest counter, the owner's pending notification and scheduled counter, and the channel's own counts: callback listeners, retained ring size and accepted notifications. An untouched linked name is not listed, which matches the probe rule. Channels a native stream drives are listed like any other.
• The field is filled on the history side in service/history/api/describeworkflow next to the callbacks and the pending Nexus operations, from the Workflow component and its LinkedChannels map, through a read-only view. Nothing is written. The frontend passes it through, so the HTTP describe route carries channelSubscriptions.
• A closed predecessor run keeps listing what it stood on, a continue-as-new successor starts empty, and a reset run lists the subscription its rebuilt History re-applied.
• tests/describe_channels_test.go covers the independent lifecycle, the linked kind with its counts, the sort across kinds, continue-as-new and reset, and the HTTP route. Unit tests cover the builder and that the response is a copy.

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

Why?

Question 5 of the proposal asked where a workflow's channel standing is visible. Until now only DescribeChannel, keyed by channel, answered, and nothing showed what a given run listens to or what it holds for its next task. With this field the CLI, the UI and the SDK descriptions show the channels next to the callbacks and the pending Nexus operations.

How did you test it?

• Unit Tests
• Staging
• End to End Tests

go build ./..., golangci-lint and the errortype vet are clean on the touched packages. Unit tests ran for ./chasm/lib/workflow/... and ./chasm/lib/channel/.... The functional tests ran with -tags disable_grpc_modules,test_dep: describe after a subscribe shows the entry with a zero last counter and the subscribe event id, a notify with no task open shows the scheduled counter at once, a notify while a task is open shows the pending notification and then the scheduled counter once the completion schedules the task, and after that task runs only the last counter remains. A linked channel appears once notified with the linked kind and its counts, a repeat joins no ring, and a callback listener is counted. A name in both kinds shows two entries in order. A continue-as-new successor shows none until it subscribes, a reset run lists the subscription under the same event id, and the HTTP describe carries channelSubscriptions with the counters as strings. The notification channel, linked channel, inline handoff and stream channel suites pass.

[moetemp]

Replaced by #18, #19, #20, #21, #22, #23, #24, #25, #26, #27, #28, #29, #30, #31, #32, #33, #34, #35, #36 and #37.

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