Prune a deployment's task data when release retention deletes it

Summary

• ServerTask and its child rows (ServerTaskLog, ActivityLog, DeploymentInterruption, DeploymentExecutionCheckpoint) were never pruned by any retention path — RetentionPolicyEnforcer only deleted Deployment + DeploymentCompletion — so they grew without bound.
• When release retention deletes a Deployment past its lifecycle/phase window, it now also deletes that deployment's task and every row keyed by its ServerTaskId (via Deployment.TaskId), so nothing is orphaned.
• The Deployment row is deleted last: if any child delete crashes mid-sequence, the surviving deployment is re-selected on the next run and the cleanup retries idempotently — no permanent orphans.
• No new control surface — rides entirely on the release-retention policy already configured per lifecycle/phase. No setting, no new field, no signature change.
• Safe because every ServerTask is a deployment task (only DeploymentService creates them; health checks write results in-place on the Machine row), so this bounds all the tables.

Test plan

• Integration (RetentionTaskCleanupTests, real Postgres, 5 scenarios): aged deployment → deployment + task + activity + logs + interruption + checkpoint all pruned; recent → all kept; currently-deployed old release → preserved with task data; multiple aged deployments → all pruned (multi-id path); aged deployment with no task (TaskId null) → pruned without error.
• Existing RetentionPolicyEnforcerTests (pure cutoff logic) unchanged + green.
• Full solution builds clean; full unit suite green.