fix(deployments-queue): reset service status to error when deployment fails

[mixelburg]

Fixes #4083

What happened

When a deployment job fails (network error, Docker daemon crash, SSH timeout, etc.), the catch block in deployments-queue.ts only logged the error. The service status set to "running" at the beginning of the job was never rolled back, leaving the service permanently stuck in a ghost "running" state with no way to recover short of manually updating the database.

Fix

Added status rollback in the catch block for all three applicationType branches:

applicationType	rollback call
application	updateApplicationStatus(applicationId, "error")
compose	updateCompose(composeId, { composeStatus: "error" })
application-preview	updatePreviewDeployment(previewDeploymentId, { previewStatus: "error" })

Each rollback call is wrapped in .catch(() => {}) so that a secondary DB/network failure cannot mask the original error in the logs.

Greptile Summary

This PR fixes a bug where a failed deployment job would leave the service permanently stuck in a "running" state. The catch block in deployments-queue.ts now resets the service status to "error" for all three applicationType branches (application, compose, application-preview), with each rollback call silenced via .catch(() => {}) to prevent a secondary DB failure from masking the original error in logs.

The fix is minimal, correct, and covers all branches symmetrically. One pre-existing pattern worth noting: the catch block does not re-throw the error, so BullMQ treats the job as completed (not failed) even when it errors — this means no automatic retry will fire and the job won't appear in BullMQ's failed queue. This behavior predates the PR and is out of scope here, but could be a follow-up improvement.

Confidence Score: 5/5

Safe to merge — fixes a real stuck-state bug with a minimal, correct change and introduces no new issues.

All three applicationType branches are handled symmetrically, rollback failures are correctly silenced without masking the original error, and the only notable concern (error not re-thrown so BullMQ treats the job as completed) is a pre-existing behaviour unrelated to this PR.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(deployments-queue): reset service st..." | Re-trigger Greptile}