(motir-core) TWO event-triggered jobs landed after MOTIR-3463's wave and are still unrouted — `plan-drift/transitioned` and `public-follow/digest` are on Inngest and no card owns them

Found while running MOTIR-3682. Same defect class as that card, different population: MOTIR-3682 is about the SCHEDULED lane and is explicitly forbidden from widening the routed set beyond its one id, so these two are not its to fix.

The measurement

Taken on origin/main at 555932db92fe0aca9d7771766e501aa0a7102ff1 (2026-08-27), and against the live MOTIR_POSTGRES_JOB_IDS read from inside motir-core machine 8576143c4ee538 at 2026-08-27T10:31Z:

git grep -hoE "id: '[^']+'" -- lib/jobs/definitions | sed "s/id: '//;s/'//" | sort -u   →  40 job ids
live MOTIR_POSTGRES_JOB_IDS                                                            →  34 ids

The six defined-but-unrouted ids, and who owns each:

Why they are unowned

MOTIR-3463 — "Cut the 20 event-triggered jobs over IN PRODUCTION" — routed 20 and is done. There are now 22. Both extras arrived after that card was authored:

• lib/jobs/definitions/planDrift.ts — plan-drift/transitioned, merged 2026-08-26 20:39Z (#2309, MOTIR-3560)
• lib/jobs/definitions/publicFollowDigestDeliver.ts — public-follow/digest, merged 2026-08-27 07:07Z (#2344, MOTIR-1103)

Both run on Inngest today, which is lib/jobs/engine/cutover.ts's documented default and is not itself broken. The consequence is deferred: MOTIR-3418 deletes the Inngest SDK and serve route on the premise that nothing remains there, and at that moment these two events lose their subscriber on both lanes — silently, with no error.

public-follow/digest is the more consequential of the two: it is the per-follower fan-out that system.public-follow-digest-tick enqueues, so once MOTIR-3682 routes the tick to the engine, the tick runs on the engine and hands its work to a job that is still on Inngest. That composition is legal (the switch is per-job and sendEvent routes each independently) but it is not a state to leave standing.

Fix direction

Add both ids to MOTIR_POSTGRES_JOB_IDS, then read one succeeded job_run row back per id from the ledger — plan-drift/transitioned by transitioning a work item on a project with an approved plan, public-follow/digest by letting the routed weekly tick fan one out (or by emitting one directly). Then extend the census in lib/jobs/engine/cutover.ts that MOTIR-3682 introduces, moving both ids from the Inngest side to the engine side; the guard test asserts the census is total over the registry, so the move is what makes the build agree with production.

Acceptance criteria

• plan-drift/transitioned and public-follow/digest are both in the live MOTIR_POSTGRES_JOB_IDS, verified from inside a machine, and the full value is recorded verbatim.
• One engine-lane succeeded job_run row is quoted per id, with its event_id and started_at.
• The three container-supervisor ids are still absent (this card must not take MOTIR-3489's scope).
• lib/jobs/engine/cutover.ts's census lists both ids on the engine side, and tests/jobs/cutover-census.test.ts is green against it.
• After this card and MOTIR-3682 and MOTIR-3489, the census's Inngest side is EMPTY — which is the condition MOTIR-3418 is premised on.

Context refs

• lib/jobs/definitions/planDrift.ts · lib/jobs/definitions/publicFollowDigestDeliver.ts — the two jobs
• lib/jobs/engine/cutover.ts — the switch, its Inngest default, and (after MOTIR-3682) the census
• tests/jobs/cutover-census.test.ts — the totality guard MOTIR-3682 adds
• MOTIR-3463 — routed 20 of 22; its record explains why