Add cooldown after metrics upload failure to prevent memory spikes

[Siddhant-K-code]

Summary

When metrics delivery fails (unreachable server, non-prod URL configured), the flush loop was attempting uploads every 3s — each blocking up to 30s on HTTP timeout while holding ~300MB of deserialized event data (Vec<MetricRecord> + Vec<MetricEvent> + serialized JSON POST body) in memory. With METRICS_UPLOAD_AVAILABLE staying true, the stream worker's backpressure also counted undrainable pending DB rows, defeating the throttle.

This adds a 5-minute cooldown (METRICS_UPLOAD_LAST_FAILURE_AT) after delivery failure:

// Before: flush_pending_metrics always attempted upload if metrics_upload_allowed() == true
// After: skips upload during cooldown, sets METRICS_UPLOAD_AVAILABLE = false
let last_failure = METRICS_UPLOAD_LAST_FAILURE_AT.load(Ordering::Relaxed);
if now_secs.saturating_sub(last_failure) < METRICS_UPLOAD_FAILURE_COOLDOWN.as_secs() {
    METRICS_UPLOAD_AVAILABLE.store(false, Ordering::Relaxed);
    return; // events still persist to SQLite, just no upload attempt
}

Both flush_metrics (buffer-driven path) and flush_pending_metrics (periodic drain path) respect the cooldown. On successful delivery after cooldown expires, the failure state is cleared. Row-level retry (mark_records_failed with exponential backoff) still handles eventual delivery once the server is reachable again.

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[Siddhant-K-code]

With this^, it starts with ~300MB, and gradually slows down to ~20 MB or so in 10-15s