fix: sweep configcheck orphans by age instead of process start

[aa1ex]

Problem

Before rolling out a config, the operator validates it in a temporary pod. The config for that pod lives in a temporary Secret, and nothing owns that Secret, so a crashed operator leaves it behind. #278 added a sweep for those leftovers: on startup, every such Secret created before the process started is treated as an orphan and deleted.

That rule breaks during an upgrade. Kubernetes starts the new operator pod before the old one stops, so for a few seconds two processes are running. The new one deletes the Secret of a check the old one is still doing. The check pod goes away with the Secret, the old process reports pod ... was deleted before producing a result, and the pipeline is marked invalid. Nobody retries it: the next reconcile sees an unchanged spec and skips the pipeline, so it stays invalid and its sources drop out of the agent config until someone touches it.

#278 has not shipped in a release yet, so no user has hit this.

Fix

A check can never run longer than its own timeout, so age is the honest test for an orphan. The sweep now deletes only Secrets older than the configcheck timeout; anything younger belongs to a check that is still running, no matter which process started it.

That holds only if the timeout really bounds the check, and it did not: the timer restarted on every pod event, and it covered just the wait for the result. It is now a single budget for the whole check - the calls that create the Secret and the pod, the request that establishes the watch, and the wait - and it starts before the Secret exists. A cluster where a check legitimately needs longer should raise --configcheck-timeout.

Two smaller things come with it. The window never shrinks below a minute, since the timeout is a flag and can be set to zero. And the sweep repeats hourly instead of running once at startup, because a Secret orphaned just before startup is too young for the first pass and nothing would look at it again.

Verification

Unit tests cover every rule, each checked by breaking the code and watching the matching test fail. Checked live as well: the old code loses a pipeline when the operator restarts mid-check, the new code does not, orphans left by a killed process are still swept, and a normal check still passes and reaches the agent config.