Webhook-based worker wake-up: let DTS call a user-provided endpoint to scale up idle workers (agents)

Summary

Add outbound webhook support to the Durable Task Scheduler so a customer can register an HTTP endpoint that DTS calls when there is pending work and no worker connected to pick it up. The wake request includes the identifiers needed to resume the right context, including the conversation ID, so the worker that comes up continues the agent exactly where it left off instead of starting a blank session. Once the worker connects, it pulls and processes the queued work as usual.

Problem

DTS is pull based. A worker has to be alive and connected to receive work. That assumption breaks when the worker is hosted somewhere that scales to zero on idle, such as a Foundry Hosted Agent, which deprovisions compute after a period of inactivity. If an event is raised while the worker is scaled down, for example a human in the loop approval or a timer firing, the work sits in the task hub with no worker alive to pull it, and DTS has no way to reach out and wake the host. Waking a worker is only half the problem. The agent's session state lives separately, keyed by conversation ID, so the resumed worker also has to know which conversation to restore or it comes back up with no memory of the run it is supposed to continue.

Proposed solution

Let the customer configure a wake up endpoint on the task hub. When DTS detects pending work with no connected worker, it sends an HTTP request to that endpoint. The request carries the identifiers required to resume the correct context, including the orchestration instance ID and the associated conversation ID. The customer's environment uses those to bring the right worker back up, which reconnects to DTS, restores the agent session for that conversation ID, and drains the pending work. This gives pull based workers the same "someone rings the doorbell when there is work" behavior that push based and HTTP triggered systems already have, while making sure the agent picks up where it left off.

No source files or tests are named. Start by tracing the task-hub path that detects pending work without a connected worker and the worker connection path; then identify how endpoint configuration and orchestration instance and conversation IDs are represented. Done means a configured endpoint receives the wake request and a newly connected worker resumes the correct queued context.