feat: support x-context extension to set Docker context in compose.yaml

[ssam18]

This adds support for an x-context top-level extension in compose.yaml that lets users pin a named Docker context for all compose operations. It removes the need to pass --context on every invocation when working with non-default contexts like rootless or remote SSH endpoints. The implementation detects the extension after loading the project and reinitializes the Docker CLI for the specified context before dispatching to the backend.

[ssam18]

@freeformz @nicksieger - Please approve the workflow and review this PR.

[glours]

@ssam18, can you clarify why this is really needed?

There are already 4 ways to define the context:

• --context flag
• DOCKER_CONTEXT defined in a .env file
• DOCKER_CONTEXT env variable in your terminal config
• docker context use command

Three of these already address the need to avoid passing --context explicitly.

In my opinion, introducing this kind of attribute in Compose would not add much value, and would instead create more ambiguity around Compose behavior.

For example, what happens if a Compose file sets x-context: contextA, while the user has DOCKER_CONTEXT=contextB in their .env file?

Or even worse, imagine a Compose file with x-context: desktop-linux, while the user has explicitly selected docker context use my_rootless_context.

I’m honestly strongly against adding this. The existing mechanisms already cover this use case, and introducing another way to define the context would make Compose behavior much more confusing and harder to reason about.

[thaJeztah]

I agree; I think this should remain an option that's explicitly chosen by the user running compose; a compose-file having x-context: my-production-machine means that a user may accidentally make changes to the production environment (but thinking they're using their "dev" environment).

[ssam18]

make sense. let me close this PR.