Track backup health: status, state file, size report

The reporting layer: one state file, the status command, and the per-run size report.

State file (the source of truth, read by status, --due, and the size report). Per database it records a two-boolean outcome, so "success" is unambiguous:

{ "<app>": { "last_run": "...", "dumped_local": true, "pushed_offsite": true, "last_success": "...", "size": 123 } }

It is written atomically after each per-database run. It is also age-encrypted and copied to R2 (in the R2 ticket), so a rebuilt VPS can rehydrate its schedule and the metadata isn't stored in cleartext.

Success semantics (defined once here, since three features depend on them):

• status is green only when the latest run had both booleans true and is within overdue_hours. Dump succeeded but push failed counts as degraded.
• --due treats a run that only made it to local as still due for the off-site copy.
• notify (the notify ticket) errors on a dump failure and warns on a push failure.

bur status [--json]: last success per database, its age and size, with a non-zero exit if any are overdue. Human and JSON output. The size report after each run shows per-database raw size (pg_database_size) against the stored .dump.age plus a ratio, a total line, and with --verbose a per-table breakdown (pg_total_relation_size).

Acceptance

• the state schema (including the two booleans) is defined, documented, and written atomically; green requires both true.
• human and --json output; overdue uses overdue_hours; the exit code reflects health; state survives a VPS rebuild via the encrypted R2 copy.
• the size report prints per-database raw vs stored plus a ratio and a total; --verbose adds per-table.