fix(worker): R1 — RPO-driven customer-backup cadence (close plans.yaml ↔ cadence drift)

[mastermanas805]

R1 — customer-Postgres backup cadence is now driven by plans.yaml rpo_minutes

Problem

The customer-Postgres backup scheduler (internal/jobs/customer_backup_scheduler.go) picked hourly-vs-daily cadence from a hardcoded switch canonicalTier() plus a hardcoded SQL tier allow-list. The hourly tiers (pro/growth/team) happened to match their advertised rpo_minutes:60, but the coupling was implicit: editing rpo_minutes in ../api/plans.yaml would NOT have moved the cadence. The product could silently over-promise RPO — sell rpo_minutes:60, deliver an effective ~24h RPO — exactly the drift R1 calls out.

Fix

Make the cadence decision read the per-tier rpo_minutes from plans.yaml — the same field surfaced on /api/v1/capabilities — so the cadence that makes the RPO true is derived from the field that promises it. They can no longer drift.

rpo_minutes	cadence	tiers
[1, 60]	hourly (every tick)	pro / pro_yearly / growth / team / team_yearly = 60
> 60	once-daily at the team's deterministic slot	hobby / hobby_plus (+ _yearly) = 1440
0 (or backup_retention_days == 0)	never enqueued	anonymous / free

What changed

• BackupPlanRegistry gains RPOMinutes(tier) int; the common-plans adapter delegates to the pre-existing common/plans.Registry.RPOMinutes. The test fake implements it too.
• NewCustomerBackupSchedulerWorker(db, plans) now takes the registry — wired in workers.go from the same backupPlans the runner already uses. A nil registry falls back to the legacy hardcoded mapping so a misconfigured boot never silently stops paid backups.
• The candidate SELECT excludes only the never-backup tiers (anonymous/free) instead of an explicit paid-tier allow-list, so a new paid tier in plans.yaml is covered automatically — this removes the single-site-list failure mode (root rule 18) that originally dropped hobby_plus + every _yearly variant for hours.
• Per-row retention <= 0 is a second, independent veto (defence-in-depth): a stray rpo_minutes on a zero-retention tier still never enqueues.

Idempotency (respected, unchanged)

The atomic INSERT … SELECT … WHERE NOT EXISTS (… INTERVAL '50 minutes') is kept — dedupe lives in the DB, not River UniqueOpts. This survives River periodic + RunOnStart double-ticks on worker restart (the WeeklyDigest-fired-daily failure mode). A second enqueue within the hour collapses to RowsAffected=0.

Tests (unit / in-memory only — no real backups triggered)

• TestScheduler_InsertsForProTierEveryHour + TestScheduler_ProDueEveryHour_AcrossAllHours — a pro resource becomes due every hour (all 24).
• TestScheduler_FreeTierNeverEnqueued + TestScheduler_FreeTierGate_SkipsEvenIfRowLeaksThrough — a free resource is never enqueued (SQL-filtered AND registry-gated if it leaks past the WHERE).
• TestScheduler_NoDuplicateEnqueueWithinHour + TestScheduler_DedupeIsAtomicInsert + TestScheduler_DedupeLookbackIsUnderOneHour — no duplicate enqueue within an hour.
• TestCadenceForTier_RPODriven (registry-iterating, not a hand-typed list) / _HourlyCutoffBoundary / _ZeroRetentionNeverBacksUp / _NilRegistryLegacyFallback.
• TestCommonPlanRegistryAdapter_Delegates extended to assert RPOMinutes against the real embedded plans.yaml (pro/growth/team = 60, anonymous = 0, hobby > 60).

No integration path that triggers a real pg_dump was added — a real hourly backup against prod customer DBs is destructive-adjacent. The scheduler only INSERTs pending rows; all assertions are against a sqlmock'd DB. No testhelpers helper was added (no per-package-coverage trap).

Gate

make gate green locally — go build ./..., go vet ./..., go test ./... -short -count=1 all pass. internal/jobs package at 96.0% coverage; all new/changed funcs at 100% (cadenceForTier, legacyCadenceForTier, RPOMinutes, ctor, Work).

---

⚠️ R2 FLAG (NOT fixed here — needs a separate change before the durability copy is honest)

Mongo / Redis / object-storage have ZERO automated backup, despite the marketing promise of "backups + 1-click restore." The entire backup ladder in this repo (customer_backup_scheduler / customer_backup_runner / customer_restore_runner) is Postgres/vector only — it pg_dumps resource_type IN ('postgres','vector') and nothing else. There is no mongodump, no Redis RDB/AOF snapshot, no S3 bucket-to-bucket sync job.

Action: until mongodump + a bucket-sync (and their restore paths) ship, every durability/backup surface — the Pro "30-day backups + 1-click restore" headline, content/llms.txt, the dashboard backup copy, /api/v1/capabilities — must say "Postgres/vector only." A Mongo or object-storage customer who reads "backups included" today gets nothing. Recommend a follow-up ticket (likely api + worker + marketing in one contract PR per root rule 22).

🤖 Generated with Claude Code