USR369 asked to chase down the instant-archive bug (done, D850) and separately confirm all current HTML pages and working files are not wrongly in trash. Ran two checks: (1) all 8 known critical live HTML pages (dashboard.html, panel.html, db-admin.html, board.html, status.html, decisions.html, info/index.html, commands.html -- the platform-html-pages backup group, D560) plus all 34 systems/commands/ whitelisted commands (same live list the post-sweep audit step uses) -- 42/42 present, zero missing. (2) Specifically traced today's actual DELETED items across all sweep runs (6 files: Server_SYNC.php_PREVIOUS x1, Server_cmd-popup_PREVIOUS x3, Server_gdrive-api_PREVIOUS x1) -- all 6 carry the _PREVIOUS_ excess-backup tag (third-or-later copies beyond the 2-version CURRENT+PREVIOUS rule, D209/D212), not live/current files. Confirmed directly: the actual LIVE, currently-serving versions of all 3 underlying files (systems/commands/SYNC.php, backend/sys-com/cmd-popup.js, backend/api/critical/gdrive-api.php) are present and intact -- only excess historical backup duplicates were removed, which is correct, intended CLEANBACKUPS.php behavior, not something the age-calculation bug caused to happen wrongly. Net finding: despite the instant-archive bug being live during multiple sweep runs today (before this session's fix, D850), no live/current file was actually lost -- the bug's real-world blast radius today was limited to command files caught by the SEPARATE stale-whitelist bug (PEEK/JANUS/ROTATE/ML, already found, fixed, and restored, D848/D849) plus legitimately-excess old backup copies that were always going to be cleaned up eventually, just somewhat earlier than the exact 8-day mark.