fix(ml-worker): cooldown gate for drift-triggered retrains so a storm cannot re-fire every poll cycle (#3168)

[Xore]

Drift-triggered retrain used a count-only gate with no time floor. The
window cleared on fire and could refire on the very next poll, which
accepted 50+ retrains in a single hour during the 2026-09-08 storm.

Fix: persisted drift_retrain_allowed() cooldown gate, survives worker
restarts (Europe/Berlin timestamps). Delays retrains only, never mutes
drift alerts. Window still clears only on the accepted-retrain path.

7 new tests added, 305 total pass.

Closes #3168

[strix-security]

Strix Security Review

No security issues found.

_{Updated for faba351.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[strix-security]

Reviewed the PR's two changed files (ml-worker/worker.py and ml-worker/tests/test_model_lifecycle.py, both inlined in the manifest) along with the surrounding run_worker and state-persistence code. The change adds a persisted cooldown gate (drift_retrain_allowed / load_last_drift_retrain / save_last_drift_retrain) plus the DRIFT_RETRAIN_COOLDOWN_MINUTES configuration to throttle drift-triggered retrains, and threads a new drift_due flag through the retrain decision. No security-relevant surface is touched: Elasticsearch access remains parameterized, no secrets or credentials are introduced, and the only new persisted input is internally written UTC state that does not reach any dangerous sink. No injection, authentication, access-control, path, SSRF, serialization, or cryptographic concerns were found in the changed code, so no validation subagents were warranted.

---

Reviewed by Strix
_{Configure security review settings}