fix(git-provider): use internal URLs for Gitea and GitLab repository …

[Siumauricio]

…cloning

• Updated the repository cloning functions to prioritize internal URLs for Gitea and GitLab, enhancing security and access control.
• Ensured fallback to external URLs if internal ones are not available.

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)

Screenshots (if applicable)

Greptile Summary

This PR extends the existing internal URL preference pattern (already used for token refresh and API calls) to the repository cloning functions in both gitea.ts and gitlab.ts. When giteaInternalUrl or gitlabInternalUrl is set, those URLs are now used for git clone, with a fallback to the external URL if not configured.

Confidence Score: 5/5

Safe to merge — the changes are small, correct, and consistent with the existing internal URL preference pattern already used throughout both files.

Both changed functions now resolve the URL via internalUrl || externalUrl, mirroring what token-refresh, API listing, and branch-fetching functions in the same files already do. The host in repoClone and the protocol flag in isSecure (GitLab) are derived from the same resolved URL, so there is no inconsistency. No new null-safety regressions are introduced. All remaining observations are P2 or lower.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(git-provider): use internal URLs for..." | Re-trigger Greptile}