fix(server): default docker build context to repo root for dockerfile builds

[azizbecha]

What is this PR about?

When the Docker Context Path field is left empty for a Dockerfile deployment, the build context defaults to the directory containing the Dockerfile instead of the cloned repository root — even though the UI placeholder advertises (default: .). With a Dockerfile in a subfolder (e.g. docker/Dockerfile), any COPY referencing files outside that subfolder fails with "not found".

There was also an inconsistency: a filled-in context path resolves relative to the repo root (code/), while the empty-field fallback resolved relative to the Dockerfile's directory — two different bases.

Changes:

• getDockerContextPath now always returns a path, falling back to the repo code root when the field is empty, so the default matches both the UI placeholder and standard docker build . convention.
• It now resolves paths using buildServerId || serverId (matching getBuildAppDirectory), so the context path is also correct when building on a remote build server.
• getDockerCommand drops its Dockerfile-directory fallback; the -f flag already passes the absolute Dockerfile path, so Dockerfiles in subfolders are still found.

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.

Verified with pnpm typecheck on packages/server and the docker-build-injection test suite (4/4 passing).

Issues related (if applicable)

N/A

Screenshots (if applicable)

N/A

Greptile Summary

The PR changes Dockerfile builds so an empty Docker context resolves to an absolute source-tree path and aligns path selection with remote build-server execution.

• Extracts provider-specific build-path selection into getBuildPath.
• Makes getDockerContextPath return a concrete path for empty values.
• Removes the Dockerfile-directory fallback from Docker command generation.

Confidence Score: 5/5

The PR appears safe to merge within the scope of this follow-up review.

No blocking failure remains among eligible new comments or previously reported findings.

_{Reviews (2): Last reviewed commit: "fix(server): default docker context to b..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Application Deployment Flow
• Knowledge Base — Server Setup and Packaging