The cron-owned approval-retention purge, previously hand-copied verbatim
by the hosts (deploy/worker.ts and the showcase worker): purgeExpiredApprovals
over the SYSTEM store (cross-tenant, cron-only — never a service method or
HTTP route, see retention.ts), 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 resolves undefined instead of
throwing, so it never aborts a caller's other maintenance duties. 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 (the snapshot purge, and — for
the showcase — the demo-tenant reaper), so logging it here too would
double-log.
The cron-owned approval-retention purge, previously hand-copied verbatim by the hosts (deploy/worker.ts and the showcase worker): purgeExpiredApprovals over the SYSTEM store (cross-tenant, cron-only — never a service method or HTTP route, see retention.ts), 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 resolves
undefinedinstead of throwing, so it never aborts a caller's other maintenance duties. 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 (the snapshot purge, and — for the showcase — the demo-tenant reaper), so logging it here too would double-log.