feat(server): add account-scoped artifact retention jobs

Review findings:

• [P1] server/lib/tuist/storage/cache_artifact_retention.ex:131 prevents cache cleanup from continuing past the first S3 page. ExAws parses IsTruncated as the XML text value ("true"/"false"), not a boolean, so this comparison never returns the next token for real S3 responses. Once a bucket has more than page_size objects, the worker deletes only page one and never enqueues the continuation job, leaving later expired cache artifacts untouched indefinitely. Please handle both the ExAws string shape and any mocked boolean shape in tests.

• [P1] server/lib/tuist/storage.ex:307 treats a 2xx multi-object delete response as full success. S3 DeleteObjects can return HTTP 200 while including per-key <Error> entries in the response body, so this can return :ok even when some objects were not deleted. The retention workers then advance their cursor/continuation token and do not retry those failed deletes. Please inspect the parsed body for delete errors before returning success.

• [P2] server/lib/tuist/storage/expired_artifacts.ex:125 skips legacy test attachments forever. The storage helper still supports the pre-test_run_id path (tests/test-case-runs/<test_case_run_id>/attachments/...) for attachments created before test_run_id was added, but this query requires attachment.test_run_id to be non-null and joins only through test_runs. Those older rows can be older than the retention window but will never be selected, so their blobs remain in object storage. Please add a legacy selection path, or otherwise include those rows when deriving the deletion key.

Additional review finding:

• [P2] The DB-backed artifact workers will re-attempt deletion for the full expired history on every scheduled run. Each worker selects rows with inserted_at < cutoff, deletes the derived object keys, and advances only within that worker chain via cursor. On the next daily scheduler run, there is no durable purged_at marker or deletion ledger, and the metadata rows are intentionally retained, so the same years-old rows still match inserted_at < cutoff and are selected again. S3 delete is idempotent, so this may not break correctness, but it means the jobs can keep issuing delete calls for already-deleted blobs forever, which works against the storage-cost-reduction goal and can create unnecessary S3/API load as historical metadata grows. We may want to use S3 as the source of truth for these artifact families too, or otherwise persist blob deletion state so the DB-backed cleanup can actually drain old work.

[P2] Keep artifact retention cursors monotonic

The new durable cursor is written with on_conflict: {:replace, ...}, so any worker that finishes later can overwrite a newer cursor with an older (after_inserted_at, after_id). The deletion workers are unique by account_id plus the cursor args, not by account/artifact alone, so a fresh scheduled no-cursor run can coexist with a cursor-followup chain for the same account/type when a backlog spans schedule windows or when multiple server pods consume :storage_retention. In that case one chain can advance the cursor, then an older duplicate page can finish and move it backwards, causing the next scheduled run to re-delete objects that were already purged. Please make the cursor update monotonic (only advance when the incoming cursor is greater than the stored cursor) and/or serialize per account/artifact. Using S3 as the source of truth, or keeping per-object purge state, would also avoid relying on a DB cursor that can regress.

Relevant code: server/lib/tuist/storage/expired_artifacts.ex:292 and worker uniqueness such as server/lib/tuist/storage/workers/delete_expired_build_archives_worker.ex:4.

Follow-up for https://github.com/tuist/tuist/pull/10983#issuecomment-4602655137: addressed in c4e03befaf.

The persisted artifact retention cursor now updates through a guarded ON CONFLICT DO UPDATE that only applies when the incoming (after_inserted_at, after_id) tuple is ahead of the stored one. If a stale worker page finishes after a newer page, the conflict update is skipped and treated as a successful no-op.

I also added a worker regression test that seeds a newer cursor, runs a stale page, and asserts the cursor stays on the newer row.

Verification: mix test test/tuist/storage/artifact_retention_cursor_test.exs test/tuist/storage/workers/delete_expired_artifact_workers_test.exs.

[P2] Don’t delete preview-level icons from app-build retention

delete_previews/3 selects expired app_builds and deletes both the app build object and AppBuilds.icon_storage_key(... preview_id ...). The icon key is preview-scoped (previews/<preview_id>/icon.png), while previews can be reused and have multiple app builds: multipart_start calls find_or_create_preview/1 and then creates another AppBuild under the same preview. That means an old app build can age past the retention window and cause this worker to delete the preview icon even when the same preview still has newer, retained app builds. The binary for the fresh app build survives, but the active preview loses its icon. Please only delete the icon when the preview itself is no longer retained / has no non-expired app builds, or track icon retention separately.

Relevant code: server/lib/tuist/storage/expired_artifacts.ex where each expired app build adds icon_storage_key, and server/lib/tuist_web/controllers/api/previews_controller.ex where previews are reused before creating new app builds.

Account-scoped artifact retention jobs are now available in server@1.205.0. Update to this version to enable plan-aware retention for previews, build archives, test attachments, shard bundles, and cache artifacts.

The changes from this PR are now available in release xcresult-processor-image@0.11.0. Account-scoped artifact retention jobs are now live.