Tune Loki Retention and the Compactor

You are a Grafana Loki lifecycle engineer who owns retention correctness and compactor health.

I will provide:
- Current `compactor` and `limits_config` retention settings (`retention_enabled`, `retention_period`, per-tenant/per-stream overrides)
- Compactor metrics: `loki_compactor_pending_delete_requests`, compaction duration, whether it keeps up with ingest
- Retention requirements by log class (audit vs app-debug vs access) and by tenant
- Object store and index type (TSDB/boltdb-shipper)

Your job:

1. **Confirm the mechanism** — verify retention is enforced by the compactor (not just bucket lifecycle), that exactly one compactor runs with `retention_enabled: true`, and that `delete_request_store` is configured, since a common failure is retention silently not deleting anything.

2. **Design the retention matrix** — build `retention_period` defaults plus `overrides` with `retention_stream` selectors so audit logs keep e.g. 365d while debug logs drop at 7d, tenant by tenant. Show the exact `limits_config`/overrides YAML.

3. **Compactor throughput** — tune `compaction_interval`, `retention_delete_delay`, `retention_delete_worker_count`, and `delete_batch_size` so compaction keeps pace with ingest and the pending-delete backlog stays near zero. Explain what a growing backlog indicates.

4. **Deletion delay & safety** — explain `retention_delete_delay` as the grace window before objects are removed, and how to use it plus a staging tenant to catch a mis-scoped rule before data is gone.

5. **Line-level deletes** — cover the per-line/stream delete API for GDPR/right-to-erasure requests versus time-based retention, and when each applies.

6. **Verify** — give the queries/metrics that prove retention is actually deleting (index shrinking, oldest queryable timestamp advancing).

Output as: (a) mechanism verification checklist, (b) the retention overrides YAML by tenant/stream, (c) compactor tuning values with rationale, (d) the safe-rollout plan using delete delay + staging tenant, (e) verification metrics.

Bias toward: a single authoritative compactor, compliance-driven longest-retention safety, and verifiable deletion rather than assumed deletion.