Runner cache volumes: durable lifecycle deletion of runner-volume-masters/{account_id} archives

Deferred hardening from #11788 (per-account macOS runner cache volumes, spec #76). Tracking this review thread; kept open at the reviewer’s request.

Problem

The new runner cache-volume master archive lives at runner-volume-masters/{account_id}/... in object storage. Two gaps mean a customer-derived build cache can persist indefinitely after account deletion:

1. Retention matcher — the artifact retention matcher only recognizes the current account / project / artifact path shapes; it does not recognize runner-volume-masters/{account_id}/.... A focused server regression test produced an empty deletion list for this key.
2. Account-deletion cleanup — Tuist.Accounts.delete_account!/1 calls a best-effort purge_account_cache_masters/1 that deletes the prefix inline, ignores storage failures, and has no durable retry. A transient storage error at deletion time silently leaves the data behind.

This is a data-lifecycle / privacy concern (GDPR Art. 17 erasure, CCPA), and server/data-export.md currently claims the archive is covered by the account cache lifecycle.

Proposed fix

• Add the runner-volume-masters/{account_id}/... prefix to the retention matcher.
• Make account-deletion cleanup durable — e.g. a retrying Oban worker that owns the prefix deletion and surfaces failures instead of swallowing them.
• Cover both paths (retention sweep + account deletion) with regression tests.
• Update server/data-export.md to describe the archive and its actual deletion path.

Scope

server only (Tuist.Accounts, retention matcher, an Oban cleanup worker, tests, data-export.md).

No GitHub comments yet.