fix: stop re-running restore and one-shot backup jobs after completion

[sionsmith]

Fixes #29.

Root cause

Three interacting defects:

1. is_job_running() only counted Jobs with status.active > 0. A completed Job has active=0, so the reconciler read it as "no job running" and created a fresh timestamped Job on every requeue.
2. Job creation ran before the completion check, so on the first reconcile after the Job finished, the duplicate was created before the status ever flipped to RestoreComplete.
3. The controllers did not watch Jobs and requeued every 300s — which is why the reporter's duplicate Jobs are exactly 5 minutes apart, and why the status sat at RestoreRunning long after the Job completed.

Successful restores were bounded at one duplicate (the RestoreComplete guard then kicks in), but a terminally failed restore Job was re-created every 5 minutes forever, and the one-shot KafkaBackup path had the identical defect. For a real (non-dryRun) restore the duplicate re-applies the restore to the target cluster.

Fix

• New jobs::job_state::classify_jobs() aggregates the full set of Jobs for a CR into Succeeded / InProgress / Failed / NoJobs, using Job conditions (Complete/Failed) so pod retries within backoffLimit stay InProgress, and a just-created Job with no status yet blocks duplicate creation.
• Job creation is gated on that classification: restores are strictly one-shot; one-shot backups only re-run via the kafkabackup.com/trigger=now annotation (which still never stacks onto an active Job).
• Both controllers now .owns() their Jobs, so completion/failure updates the CR status within seconds instead of after the next periodic requeue. RBAC already grants watch on batch/jobs; no CRD changes.
• Terminally failed restore Jobs now report a RestoreFailed condition instead of being silently re-created.
• Status patches are idempotent (Job-derived timestamps, skip when the outcome is already recorded) so the new watch cannot churn lastTransitionTime in a reconcile loop.

Verification

Reproduced the issue first on a kind cluster with the v0.2.8 operator and a stub job image: Job completed at +0:29, status stuck at RestoreRunning, duplicate Job created at exactly +5:00 — matching the report byte-for-byte.

• TDD: the new job_state tests were written against the old decision logic first — 6 of 11 failed (succeeded/failed/pending Jobs all invisible) — then the classification was fixed; all 31 tests now pass, plus clippy/fmt/helm template clean.
• E2E with the fixed operator against the same cluster, watched for 8.5 minutes (past two requeue cycles):
  • success case: exactly 1 Job; status RestoreCompleted ~0.5s after Job completion; no duplicate at +5/+9 min
  • failure case: exactly 1 Job; pod retries stayed RestoreRunning; terminal Ready=False/RestoreFailed + Error=True/RestoreFailed after backoffLimit; no re-creation
  • one-shot backup: exactly 1 Job, BackupCompleted within seconds, no re-run

🤖 Generated with Claude Code