Skip base image inspection when a named build context provides it

[Gundy (nsgundy)]

Problem

A Compose service can satisfy its Dockerfile's FROM through build.additional_contexts, e.g. to layer a dev image on another service's build:

services:
  base:
    scale: 0
    build:
      dockerfile: Dockerfile.base
  app:
    build:
      dockerfile: .devcontainer/Dockerfile   # FROM my-base
      additional_contexts:
        my-base: "service:base"

BuildKit substitutes the named context at build time, so my-base never needs to exist locally or in a registry, and docker compose build succeeds. devcontainer up fails before it gets there: getImageBuildInfoFromDockerfile resolves the final stage's FROM and inspects it (pulling on a miss), which ends in:

Error response from daemon: pull access denied for my-base, repository does not exist or may require 'docker login'

The current workaround is to seed a dummy local image under the base's name before the CLI runs.

Change

• getBuildInfoForService now returns the service's additional_contexts (mapping or name=value list form).
• Both Compose call sites pass the context names to getImageBuildInfoFromDockerfile.
• When the resolved base image matches a context name, the inspection is skipped. The user then comes from the Dockerfile's USER (or defaults to root), and no base-image metadata is used, same as the existing fallback when no base image is resolved.
• Matching follows the familiar reference form BuildKit uses for named context lookup (docker.io/library/ prefix and :latest suffix stripped).

Dockerfile-based configs passing --build-context via build.options have the same issue. I kept this PR to Compose and can follow up if wanted.

Testing

• Unit tests for getBuildInfoForService, isNamedBuildContext, and internalGetImageBuildInfoFromDockerfile with a context-provided base.
• Manually with the Compose setup above: devcontainer up fails with "pull access denied" on main and succeeds with this change; whoami in the container returns the USER from the dev Dockerfile.

[Gundy (nsgundy)]

@microsoft-github-policy-service agree