Throttle repeated rollout compression runs

[jif-oai]

Why

#25089 introduced the background worker that compresses cold archived rollouts, and #25654 made that pass faster once it starts. But the worker still deleted rollout-compression.lock on successful exit, so the existing six-hour staleness window only helped with overlapping or crashed workers. Each new local thread-store initialization could immediately rescan archived rollouts even if a full pass had just finished.

This change keeps the existing marker around long enough to throttle redundant reruns. The worker is still best-effort, but it no longer does repeated startup scans when nothing new is eligible for compression.

What Changed

• Replace the drop-scoped CompressionLock with a CompressionRunMarker that claims the existing .tmp/rollout-compression.lock path and leaves it in place after success.
• Reuse the existing six-hour staleness window to block both overlapping starts and immediate reruns, while still letting a stale marker be reclaimed.
• Update the worker docs and debug logging to describe the new "already running or recently ran" behavior.
• Extend the rollout compression tests to assert that a successful run leaves the marker behind and that a fresh marker suppresses a new run.

Validation

• just test -p codex-rollout

[jif-oai]

The failure is due to an unrelated flake