Cleanup cron: hung S3 still stalls the schedule at title-icon and bootstrap-package cleanup

[AndreyKizimenko]

Fleet versions

• Discovered: rc-minor-fleet-v4.93.0 (ca7b161)

Web browser and operating system: N/A (API)

---

💥 Actual behavior

When S3 stops responding, the cleanups_then_aggregation schedule still stalls. #49619 gave cleanup_unused_software_installers a 10-minute timeout, but the next two jobs, cleanup_unused_software_title_icons and cleanup_unused_bootstrap_packages, hit the same S3 bucket with no timeout. After the installer job times out, the schedule hangs in the title-icon cleanup until the connection drops or the server restarts, and no later job runs (cleanup_host_mdm_commands, cleanup_worker_jobs, revoke_old_conditional_access_certs, aggregation).

🛠️ Expected behavior

A hung S3 call in the title-icon or bootstrap-package cleanup gives up after a bounded time, like the installer cleanup does since #49619, and the rest of the schedule keeps running.

🧑‍💻 Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
• Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.

1. Put a proxy in front of the software installers S3 endpoint that answers every ListObjectsV2 with the real headers but never finishes the body. (In a dev setup, a proxy that sends no headers at all is cut off after 45s by the dev S3 client, so stall the body instead.)
2. fleetctl trigger --name cleanups_then_aggregation
3. After 10 minutes cleanup_unused_software_installers fails with context deadline exceeded. GET /debug/pprof/goroutine?debug=2 then shows the schedule in CleanupUnusedSoftwareTitleIcons → commonFileStore.Cleanup → ListObjectsV2, and it stays there. In QA it sat there 23 minutes until the connection was dropped.

🕯️ More info (optional)

• The title-icon and bootstrap-package stores use the same S3 config as installers (SoftwareInstallersToInternalCfg, server/datastore/s3/software_title_icon.go:13, bootstrap_package.go:14). Their jobs pass the schedule's context, which has no deadline (cmd/fleet/cron.go:1601-1609 → server/datastore/mysql/software_title_icons.go:142, apple_mdm.go:4209 → server/datastore/s3/common_file_store.go:141).
• Reliability: cleanup_unused_software_installers can stall the shared cleanup schedule #49619 assumed the installer cleanup was the only S3 caller in this schedule. The same pattern (cleanupUnusedSoftwareInstallersCronJob, cmd/fleet/cron.go:1736) would cover these two jobs.
• The generic per-job timeout in Reliability: cron scheduler runs jobs without a per-job timeout #49621 would also cover it.