Surface a clean container display name (from devcontainer.json `name`) as first-class metadata

[bilby91]

Summary

Consumers of the runtime's ListContainers currently only receive the raw Docker container name, which for the Compose path is dc-<hash>-<service>-<n> and for the single-container path is devcontainer-<hash>. There is no clean, human-friendly name to display in a UI, so consumers are forced to either show the dc-<hash>… string or reverse-engineer it with regex.

Meanwhile, the library already parses the natural friendly name — the name property from devcontainer.json — but then discards it: it's resolved into ResolvedConfig.Name and never stamped onto the container or returned.

Request

Surface a friendly display name as first-class metadata, without changing the load-bearing Compose project name. Two possible shapes (either or both):

1. Stamp a label on created containers, e.g. dev.containers.displayName = ResolvedConfig.Name. This composes with the existing label-based enumeration and is cheap for consumers to read via ListContainers (which already populates Labels).
2. Add a field to runtime.Container (e.g. DisplayName string) populated from the resolved config.

Pointers (as of v0.4.0)

• config/raw.go:16 + config/resolve.go:52 — devcontainer.json name is parsed into ResolvedConfig.Name (optional / omitempty).
• runtime/runtime.go:284 — Container struct exposes only ID, Name (raw Docker name), Image, State, Labels; no display name.
• up.go:463-467 — Compose project name is hardcoded "dc-" + DevcontainerID, which becomes the container name prefix.
• engine.go:149-152 — single-container name is "devcontainer-" + id.

Important constraint

Please keep the Compose project name (dc-<hash>) unchanged — it is load-bearing (it is the com.docker.compose.project label used for enumeration and by docker compose itself). This request is only to add separate, display-oriented metadata; it should not rename the project or the containers.

Fallback behavior

devcontainer.json name is optional. When absent, a sensible fallback would be the Compose service name for siblings and something stable (e.g. devcontainer) for the primary — but consumers can also handle fallback themselves as long as the field is nullable/empty when unset.

Context

Downstream (DAP) we're shipping a temporary display-time strip to hide the dc-<hash>- prefix in our Resources UI; this issue tracks the proper fix so we can drop the workaround.