fix(api): retry failed deployment cleanup

[AsperforMias]

Summary

• Keep an App deployment visible and retryable when Cloudflare resource deletion fails.
• Return an explicit cleanup failure instead of reporting deletion success before provider cleanup completes.
• Finalize D1 soft deletion only after all Cloudflare cleanup operations succeed.
• Fixes fix(api): make deployment cleanup retryable after Cloudflare delete failures #285.

Why

The previous ordering could hide a deployment in D1 while a Pages project, Worker, route, or custom domain remained externally reachable. A subsequent delete did not retry provider cleanup, leaving a potential security and billing orphan.

Verification

• Commands: just test-file apps/api/tests/app-deployment-service.test.ts (19 passing); just check (939 passing tests, plus format, docs, lint, type, and GraphQL checks).
• Manual steps: Used a local SQLite D1 fixture with an injected Cloudflare deployment client that fails cleanup. Verified every cleanup operation is attempted, the operation returns the explicit cleanup error, deleted_at remains unset, the active run is failed, and a later successful retry finalizes deletion.
• Not run: A remote Cloudflare Pages/Workers/Routes/custom-domain cleanup test. No Cloudflare account resources were available for an isolated remote deployment, so no remote resources were created and no account usage or billing was incurred. The local fault-injection regression verifies the database/provider failure boundary, but does not claim remote provider side effects were observed.

Impact

• User/API/contract changes: A deletion with unresolved Cloudflare cleanup now returns APP_DEPLOYMENT_CLEANUP_FAILED (HTTP 502) rather than reporting success.
• Generated files / GraphQL / DB / lockfile: N/A.
• Env or config changes: N/A.
• Risk and rollback: Existing external resources can be partially deleted before one operation fails; a retry repeats cleanup and Cloudflare 404 responses are handled idempotently. Revert this commit to restore the prior soft-delete-first behavior.

Review

• Closest review areas: App deployment deletion service, Cloudflare deployment client, deployment run lifecycle.
• Known trade-offs: The deployment stays visible until cleanup completes, making an external cleanup outage explicit and retryable rather than hiding it.

[github-actions]

All contributors on this pull request have signed the CLA.
_{Posted by the CLA Assistant Lite bot.}

[samzong]

/lgtm

[AsperforMias]

I have read the CLA Document and I hereby sign the CLA

[Yevanchen]

Verified the reorder is safe for retries: all five Cloudflare delete operations are 404-idempotent (deletePagesDomain/deletePagesProject/deleteWorkerScript swallow 404; worker domain/route use find-then-delete), so a partially-cleaned deployment converges to success on retry instead of getting stuck. deleteAppDeployment is the single writer of appDeployments.deletedAt and the single GraphQL entry point, and the web deploy surface already handles mutation errors, so the new APP_DEPLOYMENT_CLEANUP_FAILED (502, matching existing badGateway precedent) lands in an existing error path. Test covers fail -> retry -> success including run/deletedAt states. LGTM.