Fix mission relay ordering before /api/spark/run returns

[vibeforge1111]

Fix mission relay ordering before /api/spark/run returns

Why

Supervised Spark Recursive QA found a remaining fast-terminal ordering race after the Telegram consumer fix. Spawner recorded the correct mission lifecycle, but /api/spark/run relayed each event fire-and-forget and could return before the terminal webhook arrived. Telegram could therefore send a start acknowledgement and later receive an already queued nonterminal relay after the terminal handoff.

What changed

• serialize the route's Mission Control/Telegram relay deliveries in owner event order
• drain the relay queue to a stable tail before returning either the success or error response
• include events appended while an earlier relay delivery is still draining
• retain existing fail-soft behavior when a relay delivery fails
• keep relay failure logs generic and free of event payloads or identity data

Exact candidate

• base: 63bd3159d4fe5d855087a762545ac51c57fa5f77
• head: 22052aeab3e6979fd75f3bc221c5b39a3dbbe5d8
• commits:
  • 5f16a086468610877099035b309948c9f8ec277d — settle mission events before the run response
  • 0edfaff24920002f05c5bf7c143b6a6bbe4e3b71 — cover events appended during flush
  • 22052aeab3e6979fd75f3bc221c5b39a3dbbe5d8 — keep the queue helper internal to the SvelteKit endpoint
• scope: two files only, /api/spark/run and its integration test

Proof

• focused route integration: 17/17 passed
• Svelte check: 0 errors and 0 warnings
• production adapter-node build: passed
• full suite: 203/203 files and 1,306/1,306 tests passed
• dependency audit: 0 vulnerabilities
• git diff --check: passed
• independent exact-head review: clean
• worktree: clean

The late-append regression starts a flush while the first relay is blocked, appends a second terminal event after the flush has begun, and proves the flush cannot resolve until that second delivery completes. It fails the previous one-shot-tail implementation.

Release gate

Exact-head test-and-audit and secret-scan pass. The exact PR head is installed locally, strict runtime sync passes, and Spawner health is green. The installed-artifact supervised Access-5 replay now also passes: one real mission produced the chronological owner sequence mission_created -> dispatch_started -> mission_started -> task_started -> task_progress -> task_failed -> mission_failed, one common request/trace join, one natural terminal Telegram failure, no duplicate, no stale acknowledgement, no nonterminal relay after terminal delivery, no unknown_mission, and exactly one active poller. This PR is ready for normal serialized merge before Telegram #864.

Rollback

Revert this small PR. It changes no database schema, public points, installer tag, release ref, or persistent mission data.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.