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

## 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.

No files, tests, or entry points are named. Start with the five-step reproduction scenario, then compare final-agent removal with removal of one agent among several; done means ownership is identified, queued work has defined terminal or remediation behavior, and apps without workflows avoid unnecessary Durable registration.

Written by the indexing model from the issue text.