Planning bug: the COLLAPSED supervisors run on Inngest between MOTIR-3417's merge and MOTIR-3489's flip, holding one invocation for the container's whole life

Found while building MOTIR-3484 (the index-supervisor collapse), against origin/main@ccf0c7e8. The defect is in the PLAN's SEQUENCING, not in either card's own scope, which is why it is filed here rather than under the story.

The observation

MOTIR-3417 deletes the stepped supervision shape. MOTIR-3489 — a SIBLING under the epic, blocked on the story — is what adds the three ids to MOTIR_POSTGRES_JOB_IDS. So between the story's merge and that flip, the three container supervisors run their COLLAPSED loop on the INNGEST lane.

That window is not a state the story reasoned about. The other two cutovers do not have it: MOTIR-3415 and MOTIR-3416 ADDED engine capability and left every handler's shape alone, so their pre-flip window was inert. This story CHANGES THE SHAPE of a handler that is still dispatched by the old executor.

What the collapsed loop does on the Inngest lane, read off the code

Inngest re-invokes the handler from the top at each step boundary and serves completed steps from its memo. The poll loop is now ordinary code BETWEEN two steps (index-boot:<pid> and index-settle:<pid>), so on the pass that reaches index-settle it runs to completion inside ONE HTTP invocation:

• index-admit:<pid> now contains the whole admission backoff — up to INDEX_ADMISSION_BUDGETS.maxAttempts = 60 attempts on a 5 s→60 s backoff, "a little under an hour of waiting" by its own comment. One invocation.
• the poll loop runs up to DEFAULT_INDEX_TIMEOUT_MS = 30 minutes. One invocation.

Observed directly in tests/jobs/code-graph-index.test.ts: pollIndexContainer is called 8 times for a 4-poll container, because two replay passes each run the loop to completion. The reads are idempotent and the outcome is memoized, so the RESULT is correct — but each pass holds its invocation for as long as the loop runs.

The unmeasured premise

app/api/inngest/route.ts still declares maxDuration = 300. On Fly with next start that is a Vercel route-segment directive and enforces nothing — which is the whole basis of this epic and is not in doubt. What is NOT measured is whether the Inngest EXECUTOR imposes a request timeout of its own on a non-streaming function response. Production runs Inngest CLOUD, which the existing harness cannot drive: the debounce measurement (MOTIR-2994) recorded exactly this limit — "Cloud is UNMEASURED … the probe needs a Fly secret and writes into production, so it is human-gated (MOTIR-2997)."

If Cloud does cap a request, an index that outlives that cap fails with a platform error and no teardown — the MOTIR-2007 shape, returning, for the length of the window. If it does not, the window is harmless. Nobody has looked, and the whole epic descends from a bug filed on exactly that kind of unchecked sentence (MOTIR-3245).

The fix, and it is a plan change rather than code

The mitigation is already built and is one environment variable: MOTIR-3489 must run in the SAME deploy window as the story's merge, not as a later follow-up. What the plan owes is to say so — the card is currently sequenced as an ordinary post-merge operator task, which is right for the other two cutovers and wrong for this one.

Two other dispositions are available and should be weighed rather than assumed away:

1. Measure it first. A probe against Cloud settles the window's actual risk, and MOTIR-2997 already exists as the human-gated door for exactly this.
2. Hold the merge until the flip is ready. Cheapest of all if the operator is standing by, and it makes the window zero rather than short.

Acceptance criteria

• MOTIR-3489's body states that it runs in the SAME deploy window as MOTIR-3417's merge, with the reason, OR the story records why the window is safe with a measurement behind it.
• The choice between the three dispositions above is made explicitly and recorded, not left to whoever performs the deploy.
• If the window is accepted, the risk is named on MOTIR-3489 so the operator performing the flip knows what they are closing.

What this is NOT

Not a defect in MOTIR-3484 or MOTIR-3485: the collapse is what the story asks for and the code is correct on the engine, which is the lane it is being built for. Not a reason to keep the stepped shape.