Handed back the task a pending channel notification schedules.

[moetemp]

This PR hands the task a pending channel notification schedules back with the completion response, instead of sending it through matching.

What changed?

• RespondWorkflowTaskCompleted adds ms.HasPendingChannelNotifications() to the conditions that create the next task in the completion. A notification that arrived while the task ran, or that a subscribe in it was handed, gets its task in the same write, started and returned to the worker when the worker asks for one.
• MutableState.HasPendingChannelNotifications covers both the subscribed and the linked kind.

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

Why?

Before this, the transaction close scheduled the task and matching started it, which costs a second write and a dispatch for every notification that lands mid-task. A buffered Signal already gets handed back inline, so a notification now gets the same path.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

I ran the unit tests for service/history/workflow and respondworkflowtaskcompleted. The functional tests ran with -tags disable_grpc_modules,test_dep: the three inline handoff cases (a subscribed channel, a linked channel, a subscribe handed the latest), each checking one state transition for completion, schedule and start, plus the notification, linked and activity channel suites unchanged. Lint and the errortype vet are clean.

[moetemp]

Paused per the 2026-10-05 design review (the decision record is on the proposal page, section 14). Resumes in phase 2 with the CHASM notification work. The branch stays as a pin.