Same-key detection doesnt account for time, especially on single key instances

Just as the single API key on my dev instance had its rate limits reset, I saw this in the logs

```
[core] | [2026-06-22 20:55:11,676: INFO/ForkPoolWorker-2] Task collectoss.tasks.start_tasks.collection_monitor[cca120ba-5c2f-43e5-8bcf-ee015179c020] succeeded in 0.08906376201775856s: None
[keyman] | 2026-06-22 20:55:14,148 - KeyOrchestrator - DEBUG - REPLY; for: 252, platform: github_rest
[core] | [2026-06-22 20:55:14,149: ERROR/ForkPoolWorker-2] The same key was returned after a request to expire it was sent (key: REDACTED)
[core] | [2026-06-22 20:55:19,695: INFO/ForkPoolWorker-2] Found cntrb events we already have...skipping the rest
[core] | [2026-06-22 20:55:19,695: INFO/ForkPoolWorker-2] Inserting 2 events
[core] | [2026-06-22 20:55:19,709: INFO/ForkPoolWorker-2] Processing cntrb 3132 of 28389
[core] | [2026-06-22 20:55:19,944: INFO/ForkPoolWorker-2] Found cntrb events we already have...skipping the rest
[core] | [2026-06-22 20:55:19,945: INFO/ForkPoolWorker-2] Inserting 2 events

```

We should update the logic behind `The same key was returned after a request to expire it was sent` to make sure it can at least keep rudimentary track of the system time and only print that error if the same key is returned within a very short timespan (maybe 1 minute).

Overall importance/priority: very low - this is a single log line that may be misleading, we have bigger problems

Start by searching the codebase for the exact log message, "The same key was returned after a request to expire it was sent," and trace the key expiration and response handling around it. Define the short time window from the issue, then verify that the error is emitted only when the same key returns within that window and is not emitted after the rate-limit reset interval.

Written by the indexing model from the issue text.