(motir-core) `docs/jobs.md` § Scheduled jobs — there IS a scheduler now, what a missed tick does, and what the health probe still proves

Rewrite docs/jobs.md § Scheduled jobs so it describes the substrate that actually fires the jobs, and correct the two sentences elsewhere in that file that this story falsifies.

The sentence that becomes false

§ Scheduled jobs currently says, in bold:

Inngest's cron trigger means there's no separate scheduler service to run.

After this story there is one. It is not a service in the deployment sense — it is a tick inside the existing worker process, adding no machine and no environment variable — and saying exactly that is more useful to the next reader than deleting the sentence. Correct it rather than removing it, so a reader can see the constraint went away rather than that the paragraph changed.

What the section must carry after this card

• Where the scheduler runs and why there (the worker, beside the claim loop; the registry-import completeness requirement and the start-up guard that enforces it).
• The catch-up policy, per job, as the operator-facing summary — with the reasoning left in docs/decisions/job-queue-foundation.md and linked, not duplicated. The ADR is the record; this is the reference.
• How a scheduled run is identified: event_name = scheduled.{job_id} on the ledger row (already documented and still true), plus the scheduled_for key on job_queue and what it guarantees — one run per tick regardless of how many workers are running.
• How an operator declares a new cron job's disposition, so the catchUp option is discoverable from the place someone adding a job already reads: § How to add a new job and the defineJob reference at the top of the file both describe the option set.

The two corrections elsewhere in the file

1. § Registration — the failure mode to know about (MOTIR-1970). Its whole argument is that cron jobs are the tripwire for a stale INNGEST app registry. That stays true for the jobs still on Inngest — and for a MIGRATED job the same silence means something different: a dead worker or a stalled scheduler. Add that reading; do not delete the section, which is still load-bearing for every un-migrated job and is a record of a month-long production outage.
2. The defineJob reference near the top, wherever the option list appears — catchUp joins cron, retryPolicy, concurrency, idempotency, debounce.

Scope boundary

docs/jobs.md ONLY. The catch-up REASONING lives in the ADR amendment the decision card writes; this card links to it and must not restate the argument, or the two will disagree the first time one is edited.

Does NOT describe the production cutover, the current routing set, or which jobs are live on which engine — that state is a property of the deployment and changes without a commit. Point at /settings/workspace/jobs and at MOTIR_POSTGRES_JOB_IDS instead of transcribing a snapshot.

Does NOT delete Inngest-specific prose that is still true. MOTIR-3418 retires the SDK and owns the sweep that removes what stops being true then.

Acceptance criteria

• grep -n "no separate scheduler service" docs/jobs.md returns the corrected sentence, not the original — and the correction says what replaced the claim rather than merely dropping it.
• § Scheduled jobs names where the scheduler runs, the registry-completeness requirement, and the start-up guard.
• The per-job catch-up table (or a faithful summary of it) is present, with a link to the ADR section that decided it and no restatement of the reasoning.
• catchUp appears in the defineJob option reference and in § How to add a new job, so someone adding a cron job meets it without reading an ADR.
• § Registration keeps its outage record intact and gains the second reading of a silent cron job.
• No claim about which jobs are currently routed to which engine appears anywhere in the file.

Context refs

• docs/jobs.md — § Scheduled jobs (the section to rewrite), § Registration, § defineJob(options, handler), § How to add a new job
• docs/decisions/job-queue-foundation.md — the amendment to link to
• lib/jobs/defineJob.ts — the option list this reference mirrors
• lib/jobs/engine/registry.ts · scripts/worker.ts — the import-completeness requirement to describe
• lib/services/jobScheduleHealthService.ts — the probe whose meaning shifts per migrated job