Recover stranded release leases from observed progress

Recover a stranded deployment lease from authoritative progress, not from timeout or expiry. First compare the controller receipt, target descriptor, workload digests, desired replicas, and mutation journal. If the candidate descriptor never persisted and every workload still matches the prior committed release, abort that exact lease and complete the controller’s verified rollback transaction with the prior receipt. Do not delete journal rows, blindly clear the lock, or open a new release first. Limits: if target images or mutation receipts exist, this no-mutation recovery proof does not apply and deeper reconciliation is required.

Applies when: a fenced Kubernetes release fails after lease acquisition but before a confirmed commit. Keywords: Kubernetes release lease recovery rollback receipt journal reconciliation deployment fence