The maintenance-owned approval-retention purge, previously hand-copied verbatim
by the hosts (deploy/worker.ts and the showcase worker): purgeExpiredApprovals
over the deployment store, the APPROVAL_RETENTION_DAYS var parsing
(allowZero: a 0-day retention purges decided approvals immediately, the
same convention RUN_RETENTION_DAYS uses), and containment — a purge
failure logs a maintenance-error and returns an explicit failed outcome
instead of throwing, so it never aborts a caller's other duties or gets
mistaken for a successful purge. Unlike
runSlaSweepMaintenance, this does NOT log its own "maintenance" summary
line: both hosts fold the returned count into ONE combined purge log
alongside their other maintenance duties, so logging it here too would
double-log.
The maintenance-owned approval-retention purge, previously hand-copied verbatim by the hosts (deploy/worker.ts and the showcase worker): purgeExpiredApprovals over the deployment store, the APPROVAL_RETENTION_DAYS var parsing (allowZero: a 0-day retention purges decided approvals immediately, the same convention RUN_RETENTION_DAYS uses), and containment — a purge failure logs a maintenance-error and returns an explicit failed outcome instead of throwing, so it never aborts a caller's other duties or gets mistaken for a successful purge. Unlike runSlaSweepMaintenance, this does NOT log its own "maintenance" summary line: both hosts fold the returned count into ONE combined purge log alongside their other maintenance duties, so logging it here too would double-log.