Added channel subscriptions to the workflow API.

[moedash]

This PR lets a workflow subscribe to a notification channel, listen on its own linked channel, and see its subscriptions on describe.

What changed?

• workflow.subscribe_channel(name) records the subscribe command once per channel per run. workflow.linked_channel(name) needs no command, since the owner listens by construction.
• ChannelSubscription hands notifications over in order, routes them by kind, and ends with unsubscribe(). After that, closed is true and a late notification is dropped.
• The runtime routes the notifications_received job to the right handle.
• WorkflowExecutionDescription.channel_subscriptions with ChannelSubscriptionInfo.
• Markers for the live cases, which skip unless -E names a server that serves channels. There are no Core gates. The pinned Core already handles the commands and delivers the job.
• The workflow line of the channel changelog entry.

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

Why?

A workflow that waits on something outside it shouldn't poll. With a subscription it sleeps until the server hands it a notification on a Workflow Task. Notifications travel in History, so a replay sees the same ones at the same points. Describe is how an operator checks what a run listens on and what's pending for it.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

poe lint is clean. The unit cases drive a workflow instance with hand-built activations, covering the shared subscription, ordering, drops, kinds and unsubscribe. Then I ran the whole channel file with -E against a local server built from the channel server PRs. That covered a workflow receiving a client notification, the linked channel's life and its owner as an execution, polling by workflow id, both describe cases, and an unsubscribe followed by a notify that wakes nothing. Every case passed and none skipped.