fix: don't let ssh-keyscan abort SSH git clones

[weibeu]

What is this PR about?

Custom Git deploys over SSH abort before git clone when the Git host doesn't answer ssh-keyscan. cloneGitRepository runs ssh-keyscan -p <port> <host> >> known_hosts as one step of a set -e script; Hugging Face's hf.co endpoint never completes the keyscan handshake — it waits for the client's SSH identification string before sending its own, while ssh-keyscan waits for the server's — so it exits 1 and set -e kills the deploy. The clone itself works fine; a real ssh/git client sends its banner first, so hf.co responds.

Two minimal changes in utils/providers/git.ts:

1. ssh-keyscan … || true — it is a best-effort convenience; its exit code should not gate the clone.
2. -o StrictHostKeyChecking=accept-new on GIT_SSH_COMMAND — let the real ssh client record the host key on first connect (it reaches hosts ssh-keyscan cannot scan). Same TOFU trust model as a blind ssh-keyscan >> known_hosts, so no security regression; a changed host key is still refused.

GitHub/GitLab/Gitea are unaffected — they answer ssh-keyscan, so known_hosts is still pre-seeded and verified as before.

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. Reproduced the exact generated command on a real remote deploy server: with these two changes git clone git@hf.co:<org>/<repo> succeeds (host key recorded on first connect, exit 0); without them the set -e script aborts at the ssh-keyscan step and git clone never runs.

Issues related (if applicable)

closes #4604