feat(reminders): dogfood jobs' DB-stored cron schedules with a nightly stale-task sweep

[rodrigobnogueira]

@nest-native/jobs 0.2.0 shipped DB-stored cron schedules as its headline feature, but this app only exercised the enqueue-driven half of the library. Since the app exists to put the libraries under realistic pressure, that gap was worth closing.

What it adds

A nightly stale-task sweep: every task still open more than 14 days after creation gets a task.stale.flagged audit entry — reusing the app's existing convention that an audit entry stands in for a notification (same as the assignment reminder).

What makes it worth having here is what it exercises, not what it does:

• Nobody enqueues it. The claimer inserts each occurrence itself from a job_schedules row, in the same transaction that advances the schedule — a genuinely different path from the assignment reminder, which a projection enqueues.
• The schedule is declared by a boot-time upsert, the pattern the library's docs recommend. The spec pins the two properties that make that safe in a real deployment: an omitted enabled preserves an operator's runtime disable across a redeploy, and an unchanged cron preserves a pending catch-up instead of skipping it.
• The schedule carries a uniqueKey, so a slow night cannot stack runs — the spec proves a second occurrence is suppressed while one is still active.
• The handler is idempotent and reads the DB itself rather than trusting a payload, because schedule delivery is still at-least-once.

Schedules are opt-in, so app.module now passes a scheduleStore; the job_schedules table is imported from the library so the app and the engine share byte-identical DDL (the same precedent as the jobs and messaging tables). Migration 0006 is drizzle-kit generated.

Verification

Per the repo guidelines (Docker was available, so full mode was run):

• npm run test:full → base suite 90/90 green, including the 4 new schedule specs.
• The gated live-Kafka spec fails — but identically on main with these changes stashed, so it is pre-existing and unrelated. It fails at file level with no assertion output; CI never runs it (it self-skips without a broker). Flagging it rather than papering over it.
• typecheck, lint, complexity:check, build, security:audit all clean.

No library friction to report upstream this time — the boot-upsert + uniqueKey combination covered the app's needs without reaching past the public API.