Honor zero-day artifact cache retention under disk pressure

Stacks release v0.75.376 passed all test shards but its required production deployment failed with ENOSPC: https://github.com/stacksjs/stacks/actions/runs/40988407953. The failed candidate was removed and previous live releases/workers stayed active.

The installed host cleanup correctly escalated at 90% disk usage, but reclaimed no completed artifact cache. Its configured pressure value is artifactMaxAgeDays: 0; the generated find -mtime +0 predicate retains completed files until they are about one day old. The same rounding makes the normal two-day maximum effectively three days. On the real host, 261 completed archive files older than an hour occupied 4.36 GiB but remained outside that predicate. Operator cleanup of those rebuildable archives and the Bun cache recovered about 7 GiB; databases, shared app data, live/rollback releases and uploads were preserved.

Fix the owning retention generator to honor the configured artifact age with minute precision. Add real-filesystem regressions for zero-day pressure cleanup and the normal two-day boundary. Preserve the separate minimum in-flight upload/staging windows and recent completed cache reuse. Publish normally and consume the maintained package in HQ.

Related: https://github.com/stacksjs/stacks/issues/3067 and https://github.com/stacksjs/hq.training/issues/318.

Implemented and released normally as v0.16.89, source https://github.com/stacksjs/ts-cloud/commit/f5d8f945ce74edf5ca9781ace9e3794d78d370f8. Implementation: https://github.com/stacksjs/ts-cloud/commit/a653931d.

The real-filesystem test fails on the old one-hour completed archive and passes with the fix. All 47 cleanup/script/timer/locking tests pass (148 assertions), as do full type checking, build and strict lint across 913 files. A new normal-window test removes a 49-hour archive and preserves a 47-hour one. Zero-day pressure retains newly completed cache reuse for at least one minute on GNU/BSD find and preserves all separate in-flight upload/staging bounds.

Normal publisher and source CI are running; lint and types are already green. Downstream consumption remains pending actual publication.

Capacity clarification: the persistent deployment failure was traced to the separate full managed release volume, not the root filesystem cache. That is independently tracked at /stacks/stacks/issues/3068. This retention fix is valid, but does not claim to restore capacity on the release mount or complete the blocked SDK publication/native acceptance.

Completed in the normally published v0.16.89, source https://github.com/stacksjs/ts-cloud/commit/f5d8f945ce74edf5ca9781ace9e3794d78d370f8.

• Full source CI and the normal publisher succeeded.
• The source regression fails on the old one-hour completed artifact. All 47 source cleanup tests pass with 148 assertions; full types, build and strict lint pass. Through the actual installed public package exports, 45 cleanup checks pass with 141 assertions.
• HQ installs the published package normally at https://github.com/stacksjs/hq.training/commit/3a6f7392b. Full HQ generation/types/lint and eight deployment/isolation tests (52 assertions) pass.
• Normal Stacks CI/deployment succeeded at https://github.com/stacksjs/stacks/commit/530261e664216f37c86f6e33a5d80c6e85bd7e90. The installed shared-host cleanup script now has the minute-precision predicate and one-minute minimum. Active Stacks, HQ and ReviewOS services were verified after deployment.

The separate release volume capacity issue is tracked at /stacks/stacks/issues/3068. It now has staging room after normal managed volume growth; SDK publication remains tracked there. This closure does not claim LSU native checkout/voice acceptance or a new HQ backend deployment.