fix(build,compose): resolve dockerfile path per Docker semantics

[jahirvidrio]

What problem does this solve?

mocker build -f <abs path> <abs context> fails with Dockerfile not found at <doubled-path> because ImageManager.build calls URL.appendingPathComponent on the dockerfile argument, which doesn't treat absolute paths as special — it concatenates them onto the build context. The fileExists guard then throws before container build is ever invoked.

Per docs.docker.com (docker buildx build --file): an absolute -f is used verbatim, a relative -f is resolved against the current working directory. mocker now matches both.

Naïvely fixing only mocker build would have shifted Compose (which reuses ImageManager.build) from context-relative dockerfile resolution to CWD-relative — a regression, because the Compose spec resolves build.dockerfile relative to the service's build.context. Both surfaces are corrected together so the Docker-compat contract holds on both:

• absolute -f → used verbatim
• relative -f → CWD-relative for mocker build, context-relative for Compose
• omitted → <context>/Dockerfile

What changed

• Sources/MockerKit/Image/ImageManager.swift: extracted resolveContextPath(context:cwd:) from the inline absolute/relative branch in build (de-duplicates the same logic that lived inline); added pure resolveDockerfilePath(context:dockerfile:cwd:) with cwd injected so it is testable without the filesystem; added public static composeDockerfilePath(context:dockerfile:cwd:) that chains the two so Compose can pre-resolve the dockerfile against its context — no new path-resolution policy added, just reuse. build(dockerfile:) parameter widened from String = "Dockerfile" to String? = nil so the three branches (nil / absolute / relative) stay distinguishable end-to-end.
• Sources/Mocker/Commands/Build.swift: @Option var file is now String? so ArgumentParser surfaces "not provided" as nil instead of the literal "Dockerfile".
• Sources/MockerKit/Compose/ComposeOrchestrator.swift, Sources/Mocker/Commands/Compose.swift: pre-resolve the dockerfile via composeDockerfilePath before calling imageManager.build, so a relative build.dockerfile stays context-relative.

How was it tested?

swift test: 151/151, 0 failures (14 new tests). 12 pure resolver tests in Tests/MockerKitTests/ImageManagerBuildArgsTests.swift cover all three branches, the CWD-vs-context divergence, the original doubled-path case, and Compose context-relative resolution; 2 parse tests in Tests/MockerTests/CLITests.swift assert -f omitted parses to nil.

Any breaking changes?

No. Widening dockerfile: String = "Dockerfile" to dockerfile: String? = nil on ImageManager.build is source-compatible: callers that omit dockerfile: keep using the default, and callers passing a String literal widen implicitly to String?. No existing call-site outside the two Compose sites updated above required modification.

[us]

Nice fix 🙏 The absolute/relative split matches buildx semantics, and handling the Compose context-relative case in the same PR (instead of leaving it as a follow-up regression) is exactly right. The resolver tests cover the CWD-vs-context divergence cleanly.

One optional, non-blocking nit: composeDockerfilePath could take dockerfile: String? and forward nil straight to resolveDockerfilePath, dropping the ?? "Dockerfile" at both call sites and keeping the default in one place. Totally fine to leave as-is.

Approving — thanks for the thorough tests and write-up!