fix(cache): set server-side TTL on model-monitoring zset writes

[bigbitbus]

Problem

RedisCache.zadd() accepts an expire argument but never issues a Redis EXPIRE — it only records the intended expiry in the in-process self.zexpires dict, which is reaped by the _expire() daemon thread:

self.client.zadd(key, {value: score})
if expire:
    self.zexpires[(key, score)] = expire + time.time()   # in-process only

That bookkeeping lives solely in the writing process's memory. If the process dies before a member is trimmed (e.g. an autoscaled/serverless inference pod scaling down), the key is orphaned in Redis forever with TTL -1.

The model-monitoring buffer in ModelManager (core/managers/base.py) writes one record per inference into inference:<GLOBAL_INFERENCE_SERVER_ID>:<model_id> (plus error:<…> and a models registry zset) via this path with expire=METRICS_INTERVAL * 2. The intended lifetime is ~120s — just long enough for the PingbackInfo scheduler to read the trailing window and POST it to Roboflow. But because GLOBAL_INFERENCE_SERVER_ID is unique per pod and pods churn constantly under autoscaling, every pod death strands its keys (a surviving pod only reaps its own ids via its own zexpires).

Impact observed in production

The redis cache got full of the model-monitoring keys and had to be manually cleared.

Fix

Issue ZADD + EXPIRE in a single pipeline so the key carries a real server-side sliding TTL:

if expire:
    with self.client.pipeline() as pipe:
        pipe.zadd(key, {value: score})
        pipe.expire(key, max(1, int(expire)))
        pipe.execute()
    self.zexpires[(key, score)] = expire + time.time()
else:
    self.client.zadd(key, {value: score})

• A live model keeps re-arming the TTL on every write (and _expire() still trims individual members), so an actively-served key never expires out from under its readers.
• A dead pod's keys self-reclaim ~expire seconds after the last write, regardless of process lifecycle — no more orphans.
• The two commands run in one transactional pipeline (MULTI/EXEC), so there is never a window where the key exists without a TTL — a crash between the two can't reintroduce the leak one key at a time.
• max(1, int(expire)) guards against EXPIRE 0 (immediate delete) for sub-second values.
• The in-process self.zexpires bookkeeping is retained as a best-effort fine-grained per-member trim (now an optimisation rather than the only safety net).

This is semantically what the existing code already intended — it just put the expiry in the wrong place (a Python dict instead of Redis). It applies to every zadd writer (model-monitoring, WebRTC session sets, etc.) for free; no caller changes needed.

Testing

New unit tests in tests/inference/unit_tests/core/cache/test_redis_cache.py:

• expire set → pipelined ZADD + EXPIRE(key, 120) issued, bookkeeping recorded
• sub-second expire floored to 1 (never EXPIRE 0)
• no expire → plain ZADD, no pipeline / TTL / bookkeeping

tests/.../core/cache/test_redis_cache.py ......... 3 passed
tests/.../core/managers/test_base.py + test_metrics.py ... 41 passed

Existing model-monitoring manager tests pass unchanged (the zadd signature is untouched).

[iurisilvio]

PR looks good, commenting just because it is a common error, ZADD EXPIRE applies to the root key, not for every item. If we keep ZADDing, I think root key will never expire.