Guard worker build and task queue retirement against live dependencies #519

User problem and decision

Promotion does not make old pinned runs or recorded activity queues independent of the old fleet. An operator needs a supported answer to “can this build or queue be retired safely?” and a guarded action, not only a warning to manually keep workers forever.

This is the product capability behind durable-workflow/durable-workflow.github.io#262, #274 and #308. Retain their accurate current promotion/routing documentation; that does not deliver safe-retirement enforcement.

At DeploymentLifecycleService::drain, Core's planner receives no pinned-run/recorded-queue dependency inventory. DeploymentLifecyclePlan::evaluateDrain can permit an active deployment without proving those dependencies are gone. #317 already delivered routing diagnostics; it did not prevent unsafe retirement.

Acceptance

• Expose a bounded, namespace/queue/build-scoped retirement inspection covering passive open pinned runs, continue-as-new chains, children, recorded activity queues, delayed retries and pending/leased tasks. An empty ready-task count is insufficient.
• Add an explicit guarded retirement operation. Preserve the separate emergency-drain contract deliberately; do not silently change an existing operational action without compatibility review.
• Refuse unsafe retirement with concrete blocker identities/counts, observation completeness and a safe recovery action. Missing/stale/incomplete inventory is unavailable, not permission to retire.
• Make the check/action safe against concurrent starts, task creation, retries and continuation. A non-atomic zero-count preview is not an enforcement barrier.
• Preserve recorded run build pins, activity queues, original history and deadlines. Do not automatically re-pin or reroute existing work. Compatible upgrades and any future migration API need their own explicit policy and tests; coordinate Changed Python workflow definitions silently strand in-flight runs #518.
• Prove a parked old-build run and a delayed old-queue activity retry block retirement even while the promoted new fleet is healthy. Then complete/drain their real dependencies and prove retirement succeeds. Test isolation, cancellation, restart and continued chains.
• Expose the workflow through CLI/SDK/operator views and publish the actual promotion, retirement and recovery journey. Keep existing BuildId filters useful as manual inspection without misrepresenting them as the guarded action.

Priority P2, additive operations-safety feature. General owns PHP/CLI/package implementation after an agreed source window. Native/shared adoption remains separately qualified under #325; frozen cohorts do not change through this issue.