Add resilient reminder retry monitoring

[partyplatter08-lab]

/claim #130

Summary

• Persist reminder delivery job state on the existing reminders table: status, retry count, max attempts, next retry, last attempt, sent/failed timestamps, and last error.
• Route /reminders/run through retry-aware processing so failed deliveries are not marked sent; failures schedule configurable backoff and eventually move to a dead-letter FAILED state.
• Add authenticated monitoring and manual recovery APIs: GET /reminders/jobs/stats, GET /reminders/jobs?status=..., and POST /reminders/{id}/retry.
• Add Postgres schema compatibility updates, OpenAPI docs, README operator notes, and tests for retry, max attempts, manual retry, backoff windows, and user isolation.

Assumption

This is scoped to the current persisted reminder/background dispatch path rather than introducing a separate generic queue dependency. That keeps the patch aligned with the app's existing cron/APScheduler-style /reminders/run workflow.

Validation

• black --check . from packages/backend: passed
• flake8 . from packages/backend: passed
• python -m pytest -q from packages/backend: 26 passed
• bandit -r app -ll from packages/backend: no issues identified
• Backend Docker image build: passed via tar-stream context
• API smoke: register/login, create due reminder, failed run -> RETRYING, monitoring stats/list, manual retry, simulated provider recovery -> SENT