Define safe lifecycle behavior when the final workflow-enabled agent is removed

[TsuyoshiUshio]

Problem

Dynamic Workflows registers the Durable orchestrator and Activities only when at least one agent has workflows.enabled: true. If the final workflow-enabled agent is removed, app composition returns to a plain FunctionApp and no longer registers those Durable Functions.

An existing orchestration may still have a queued but unexecuted Activity work item. After the final agent is removed, there is no registered Activity Function to receive that item, so the instance cannot reach the runtime's deployed-policy reauthorization boundary and fail explicitly. It may remain non-terminal in the Task Hub.

This differs from removing one of several workflow-enabled agents: the shared Durable runtime remains registered, so pending Activities for the removed agent execute and fail closed because its policy is absent.

Why this is not addressed with an application setting

PR #151 briefly introduced AZURE_FUNCTIONS_AGENTS_WORKFLOW_DRAIN_MODE to retain the Durable runtime with an empty policy catalog while blocking new application-level starts. After offline design review, we decided not to publish this customer-facing environment variable:

• this is an edge-case deployment lifecycle concern;
• a public operational switch would become a compatibility commitment once released;
• correct ownership may belong in Durable/runtime lifecycle semantics rather than the agent authoring surface;
• an application-level switch cannot guard privileged direct Durable control-plane starts and still requires external Task Hub inspection.

The setting and its implementation are being removed before release.

Desired outcome

Define the supported lifecycle and remediation for removing the final workflow-enabled agent while non-terminal instances may exist. Options to investigate include:

1. Durable/runtime support for retiring orchestrators and Activities without stranding queued work.
2. A deployment-time or Task Hub-aware mechanism that detects non-terminal instances before Durable Functions are unregistered.
3. A runtime-managed tombstone/drain behavior that is not exposed as a permanent customer authoring or environment-variable contract.
4. Explicitly documented operator behavior if this must remain an unsupported transition.

Acceptance criteria

• The owner of the behavior (agent runtime versus Durable Functions/Durable Task Scheduler) is identified.
• The final-agent removal sequence has defined behavior for queued Activities and non-terminal orchestrations.
• Existing instances either reach a terminal state or operators receive an actionable, supported remediation path.
• Ordinary apps with no workflow-enabled agents continue to avoid unnecessary Durable registration overhead.
• Any public surface is reviewed as a long-term compatibility commitment before release.

Reproduction scenario

1. Deploy one workflow-enabled agent and start a workflow containing a capability-bearing Activity.
2. Ensure the Activity work item is queued but has not executed.
3. Deploy a version with no workflow-enabled agents.
4. Observe that the app is now a plain FunctionApp and the workflow orchestrator/Activities are absent.
5. Observe whether the queued instance remains non-terminal because no Activity Function can receive the work item.