feat: add support for 'labeled' action in GitHub deployment handler

[Siumauricio]

What is this PR about?

Please describe in a short paragraph what this PR is about.

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 (if applicable)

closes #3956

Screenshots (if applicable)

Greptile Summary

This PR adds "labeled" to the shouldCreateDeployment condition in the GitHub webhook handler, enabling preview deployments to be created (not just re-triggered) when a label is added to a pull request.

Key changes:

• action === "labeled" is now included in the shouldCreateDeployment boolean, which gates the createPreviewDeployment call at line 484
• This fixes the case where an app is configured with previewLabels (e.g., ["deploy-preview"]): previously, if a PR was opened without the required label, no preview deployment was created; when the label was later added, shouldCreateDeployment was false, so no new deployment was ever created — the label-based trigger was silently a no-op for net-new deployments
• The label-matching check at lines 462–472 (app.previewLabels vs pull_request.labels) correctly evaluates the post-label state, so only apps whose configured labels match the PR's current label set proceed to deployment

Minor behavioural side-effect to be aware of: For apps that have no previewLabels configured (i.e., they deploy on all PR events), adding any label to a PR could now create a new preview deployment if one does not already exist for that PR. In practice this is harmless — if such an app is configured to react to all PR events it will already have a preview deployment from the opened event, so findPreviewDeploymentByApplicationId will return the existing record and no new deployment is created; the existing one is simply re-queued.

Confidence Score: 5/5

• This PR is safe to merge — the change is a one-line, well-scoped fix with no regressions in the surrounding security or deployment logic.
• The diff is a single-condition addition inside an already-gated block. All existing security checks (webhook signature verification, collaborator permission validation, label-matching filter, previewLimit guard) apply equally to the labeled action with no new code paths introduced. The fix correctly addresses the root cause reported in Preview deployments with previewLabels fail due to webhook race condition #3956.
• No files require special attention.

_{Last reviewed commit: e554adc}