[lweberru]

CF can finish deleting a stopped Runner after the immediate observation window. The app disappears, but its cleanup receipt was then lost. Persist a space/origin-bound intent immediately before deletion and confirm it in later maintenance passes, including after API restarts. Confirmation only reads CF and records a receipt after HTTP 404; the existing deletion safety checks remain enforced.

Migration 078 adds a protected, bounded and fairly polled confirmation queue. Individual CF/database failures are isolated so one entry cannot block other confirmations or the normal sweep. English and German execution documentation describe the behavior.

Validation: full local app checks; PostgreSQL identity/Runner-pool integration (70 tests); delayed completion, restart, scope isolation, idempotency, protected access and per-entry failure regressions. Independent review completed without outstanding findings. Assistant implementation and its qualified knowledge binding are unchanged.

Dev deployment verified: release 40705856040 completed successfully with runner_pool_size=1 and the Assistant enabled. The final delta used the explicit Dev qualification exception; the unchanged Assistant binding had already passed the complete source-bound qualification.

Read-only runtime checks confirmed migration 078, the current source-bound ready Runner, preserved recovery evidence and absence of four legacy execution apps. A disposable empty, route-free CF app then exercised delayed deletion: normal API maintenance confirmed its absence, wrote a receipt and removed the pending intent. No customer jobs, infrastructure State or locks were changed.