Add panic supervision for the keeper and reconciliation background loops

[Smoothjane]

Summary

Both the subscription-keeper and batch-reconciliation background loops were launched with a bare tokio::spawn and never supervised — a single panic anywhere in either call graph (an unwrap(), an array index, or the companion chrono::Duration::seconds() overflow near i64::MAX on reconciliation_stale_after_secs, which is directly reachable in run_batch_reconciliation_loop) silently and permanently killed that loop for the rest of the process's lifetime, with no line in the structured tracing log stream — just an absent stderr backtrace most containerized/log-shipped deployments would never surface distinctly from noise.

Implemented both layers the issue asks for:

• run_isolated_pass: wraps each loop's per-pass body (service construction + the actual call) in its own tokio::spawn, so a panic there surfaces as a JoinError the outer loop can log and continue past — the loop's own loop { interval.tick().await; ... } never panics itself.
• supervise_loop: an outer, defense-in-depth layer — retains the JoinHandle (previously dropped entirely) and restarts the task with a capped exponential backoff (1s → 60s, resetting after a 30s+ healthy run) if it ever terminates for any reason, rather than vanishing.
• BackgroundLoopHealth: tracks each loop's last-completed-tick unix timestamp (updated even when a pass panics — the loop is still alive), exposed via /health's background_loops field — ties into Keeper background job has no metrics, alerting, or observability into failure trends #25's observability scope as the issue's acceptance criteria suggests, without building the fuller metrics/alerting system that's explicitly Keeper background job has no metrics, alerting, or observability into failure trends #25's job, not this issue's.
• Both loops' panics (and the recoverable-Err path, unchanged) now log through the same structured JSON tracing pipeline as every other error in the codebase, not a bare stderr backtrace.

Test plan

• Unit tests for run_isolated_pass (success passes through; a panic is caught as a JoinError, not propagated to the caller)
• Unit tests for supervise_loop (restarts after a panicking task; restarts after a task that returns normally instead of running forever)
• An end-to-end-style test mirroring the real loops' exact tick/pass/match structure (not just the helper in isolation) — deliberately panics on one pass and asserts every subsequent tick still runs, per the issue's acceptance criteria
• cargo test — 38/38 passing (11 pre-existing #[ignore]d db_tests require a live Postgres, matching this repo's existing convention — untouched by this change)
• cargo check — clean

This repo's only CI workflow is cargo-deny (supply-chain/license audit) — no test/build/lint workflow exists. Ran it locally: it reports one pre-existing advisories failure (RUSTSEC-2026-0258, a transitive h2 vulnerability) that's unrelated to this change — Cargo.toml/Cargo.lock are untouched by this PR, and the same failure reproduces on a clean, unmodified upstream/main checkout.

Closes #50

[abayomicornelius]

all ci passed