feat(operator): autogrow kopia cache PVC on persistent pressure

[passcod]

🤖

Summary

Self-tuning loop for the kopia cache PVC. Composes two halves:

1. Pre-flight (in the restore Job): if cache PVC usage ≥85% before kopia starts, evict the regenerable content (`/tmp/kopia/cache` and `/tmp/kopia/logs/content-logs`). Prevents the "kopia can't write its 4KB config" failure mode that triggers when the PVC hits 100%.
2. Autogrow (in the operator): when the pre-flight eviction fires, the Job POSTs to a new operator endpoint, and the operator bumps the cache PVC's requested storage by 15%. Capped at 2× the snapshot-derived default.

Result: a chronically-pressured replica converges to a working PVC size over a handful of restore cycles. A one-off spike grows the PVC once and stops. No manual intervention.

Signal path

Uses an HTTP callback rather than pod-log scraping (the same pattern as the snapshot-list and schema-migration jobs already use).

```
POST /api/v1/cache-pressure/{namespace}/{restore}
```

Empty body — the path identifies which restore (and therefore which replica's cache PVC and which snapshot size) to bump. Handler in `bin/operator.rs` calls into `controllers::restore::grow_cache_pvc_after_pressure`.

Shape

• New helpers in `controllers/restore/builders.rs`:
  • `KOPIA_CACHE_PRESSURE_GROWTH_FACTOR = 1.15`
  • `kopia_cache_pvc_max(snapshot)` — 2× the default size, the growth cap.
  • `next_cache_pvc_size_after_pressure(current, snapshot)` — current × 1.15, capped.
• New `grow_cache_pvc_after_pressure` in `controllers/restore.rs` — patches the PVC's `spec.resources.requests.storage`. Best-effort; logs and continues on failure.
• New `Context::cache_pressure_callback_url` and `/api/v1/cache-pressure/{namespace}/{restore}` route.
• `build_restore_job` takes the callback URL and sets it as `CACHE_PRESSURE_CALLBACK_URL` on the restore container; the embedded script POSTs to it when pre-flight evicts.

Tests

• `next_cache_pvc_size_after_pressure_bumps_and_caps` — verifies bumps grow then saturate at the 2× cap.
• `restore_job_passes_cache_caps_and_log_rotation` extended to require the new env var and the script's POST step.

Caveats

• Growth depends on the storage class supporting volume expansion (we already rely on this for the snapshot-growth ratchet). Failure is logged and the restore proceeds with the existing size.
• Growth is permanent (never shrinks), matching the existing PVC-resize pattern.