feat: display queued status within individual service deployments

[imrja8]

What is this PR about?

This PR resolves an issue when pending deployments waiting in the background queue were completely invisible inside a specific service's "Deployments" tab (Project -> Environment -> Service -> Deployments).

When another service deployment is already running, subsequent deployment requests are placed in a queue. Because these queued deployments didn't appear in the service deployment list until they actually started running or failed, users would assume the deployment was missing or had not started. This caused confusion and led to users clicking "Deploy" multiple times, inadvertently spawning duplicate deployment triggers.

Note: I did not block the user from hitting the deploy button when another deployment is running. Instead, the UI simply shows them that their deployment is "Queued", providing immediate visual feedback so they know the system registered their request.

By introducing a "queued" state directly to the deployment schemas and logs, users now get immediate feedback inside their individual service view.

Key changes included in this PR:

• Database Schema: Added a new "queued" status to the application, compose, and deployment schemas (with generated Drizzle migrations).
• Service Deployment Logs: Refactored deployment creation to immediately write the deployment to the database and generate an initial log file: "Job queued... waiting for an available worker".
• Worker Hand-off: When the background worker picks up the job, it flips the DB status from "queued" to "running" and appends "Worker picked up job, starting build..." to the log file.
• UI Visibility: Added a distinct purple "Queued" badge in status-tooltip.tsx and updated strict TypeScript Services interfaces in the frontend UI components to safely handle the new status without throwing type errors.

Note: I intentionally did NOT add the "queued" state to the global /dashboard/home recent deployments view. The sidebar's "Deployments" page already has a dedicated "Queue" tab (/dashboard/deployments?tab=queue) for upcoming jobs. Keeping them out of /dashboard/home preserves the existing design decision to keep the global view split without cluttering the main list of active/finished jobs, while fixing the missing visibility inside the service deployments.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related

closes #4762

Screenshots

1. Queued Service Indicators: The blue "Queued" indicator is now visible on the service card in the project page while it waits.

2. Active Deployment: The first service is currently running and occupying the worker (just added to show that one deployment is already running).

3. Queued Deployment: The second service is immediately shown as "Queued" while it waits for the first service to finish. It also has a blue indicator while it waits.

4. Queued Deployment Successful: Status transitions natively from queued, to running, to finally done (deployed) green.

5. Global Queue Tab (Existing Behavior Preserved): The global Deployments -> Queue tab still functions exactly as before.