Implement the stale "processing" record reaper

The project's own README says this out loud, in "Known limitations": background tasks run in-process with no external queue, so "a process restart loses any task that hadn't started yet (though the record is left at status='processing' in the DB, not silently lost -- a production hardening step would be a periodic sweep that requeues stale 'processing' rows...)". That hardening step has never actually been written. Today, any deploy, crash, or OOM-kill that happens to land between "record created with status=processing" and "background task commits ready/failed" leaves that row stuck at processing forever, with no code path that ever revisits it. To the uploading user, their image never finishes: no error, no thumbnails, just permanent "processing" -- the single worst failure mode this service can produce, because it looks like the request is still in flight when it has actually been abandoned. Every such row is also invisible to normal monitoring (nothing errors, nothing logs) -- the only way anyone finds out today is a user complaining that their upload "has been stuck for 3 days."

app/maintenance.py exists with the function signature reap_stale_processing_records(session_factory, storage, stale_after_seconds) already defined, matching the shape a periodic job (a cron entry, a Celery beat task, a sidecar loop -- deliberately not wired up here, since the scheduler choice is out of scope for this ticket) would call it with. The body is a stub: it unconditionally raises NotImplementedError.

cd fastapi/image_service && source .venv/bin/activate pytest -q practicetickets/test_ticket07_stale_processing_reaper.py -v

-> Failed: reap_stale_processing_records(...) raised NotImplementedError(...)

This is the same "the response and the work are two different lifetimes" lesson the whole project is built around (see the README's opening section) taken to its logical conclusion: if the response already happened but the work never will, the record needs a way to notice that on its own, since the client that originally uploaded is long gone and isn't coming back to complain in a way the system can act on. updated_at on ImageRecord (app/models.py) is already stamped onupdate=... on every row change, which makes it exactly the signal needed here: a processing row whose updated_at hasn't moved in a long time is a row whose background task is never coming back. This is also the shape every real production hardening of this pattern eventually takes, whether the actual scheduler ends up being a cron entry, a Celery beat task, or a sidecar loop -- the reaping logic itself is scheduler-agnostic, which is exactly why this function takes session_factory and stale_after_seconds as plain arguments instead of assuming anything about how or when it gets called.

You'll query models.ImageRecord for rows matching both conditions above -- similar in spirit to the querying you'd write for ticket 03's list endpoint, but filtered by status and updated_at instead of paginated. Use session_factory() to get your own session (the same pattern run_thumbnail_pipeline in app/main.py uses for its own out-of-request session), and be careful about timezone-awareness when comparing against updated_at -- look at how models.py stamps it (datetime.now(timezone.utc)) and compare like-for-like. The storage parameter is there in case your implementation wants to account for a partially-written thumbnail from a task that died mid-write; a minimal, correct implementation does not strictly need to touch it.