Retention backs off after a failed protection census and shows it in health
Follow-up to #1094. A full fleet-scale fixture (30,000 shell tasks, 1,372 sessions, 350,000 files, 50 trash entries) shows one retention pass with the streaming census finishing well inside the 60 s budget: 0.6-0.9 s on Linux, 6.8 s wall / 3.7 s CPU on macOS, reclaiming all 50 entries. (The live daemon's endless "repair traversal limit exceeded" retention predates #1060 and #1094.) Finished task bundles still need alias protection, so the census stays complete rather than narrowed to running tasks.
What changes: when a protection census can't finish, retention backs off 20, then 40, then at most 60 minutes instead of re-running the full census every pass; health shows the typed failure and protection_retry_at_ms; a successful census clears the backoff at once. Tests: the scale fixture (full size behind AFT_STRESS=1; the default size exercises a census cut-off that deletes nothing) and backoff clearing after a successful retry.
Summary by cubic
La retención espera 20, luego 40 y como máximo 60 minutos después de un censo de protección fallido, en lugar de repetir el censo completo en cada pasada. La salud muestra el fallo tipado y protection_retry_at_ms, y un censo exitoso limpia el respaldo de inmediato.
Un fixture a escala de flota (30 000 tareas, 350 000 archivos) completa el censo en 0,6–0,9 s en Linux y ~7 s en macOS, manteniendo la protección completa de alias, incluidos los paquetes de tareas terminadas; solo los casos de estrés reducido ejercitan el corte que elimina cero entradas.