dev_container: Resolve compose dockerfile path relative to build context

[antont]

Context

When a Docker Compose service specifies context: .. and dockerfile: .devcontainer/Dockerfile, Zed resolves the dockerfile path relative to the compose file's directory instead of the build context. This produces a doubled path like .devcontainer/.devcontainer/Dockerfile which doesn't exist.

Per the Docker Compose spec, the dockerfile field is relative to the build context directory.

The fix resolves the context directory first (relative to the compose file), then joins the dockerfile path to that.

Closes #53473

Prior art

This fix is extracted from #53170 by @zdeneklapes, which addresses this bug among several other dev container startup issues. This PR isolates the dockerfile path resolution fix into a focused change to make it easier to review and merge independently.

Differences from #53170:

• Scope: Only the dockerfile-relative-to-context fix, not the other fixes (compose build args preservation, remote user fallback, Docker inspect labels, etc.)
• Implementation: Inline resolution in dockerfile_location() rather than separate helper methods
• Absolute path handling: Handles absolute dockerfile and context paths
• Tests: Two test cases — compose file inside .devcontainer/ with context: .., and compose file at project root with context: .

How to Review

Single file change in crates/dev_container/src/devcontainer_manifest.rs:

• Fix (line 234-252): Resolve build context relative to compose file directory, then join dockerfile to that, instead of joining dockerfile to config_directory directly. Uses normalize_path to resolve .. components.
• Tests: Two new FakeDocker compose config entries and corresponding tests asserting correct resolved paths.

Self-Review Checklist

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• Fixed docker-compose dockerfile path being resolved relative to the compose file instead of the build context directory.

[KyleBarton]

@antont thanks for this! Generally looks good - can you run cargo fmt --all and cargo clippy --workspace --release --all-targets --all-features -- --deny warnings (and fix any issues flagged therein) so that CI can go green?

[antont]

@KyleBarton oops, sorry I forgot that chore again, it's done now!

BTW this was not enough to get my work system working with the new code but I encountered a new error, apparently because the dev container includes several containers (Postgres and localstack in addition to our project) so the docker ps output parsing failed (docker ps --format={{ json . }} returns one JSON object per line, and deserialize_json_output chokes on the multi-line output)

With that additional fix my work project's dev container launches fine: #54068

I had to resort to using an old official release in the meantime, but now am back using main + patches for work.