perf(docker): socket-activate dockerd instead of starting it at boot

[runleveldev]

Summary

The docker image currently runs systemctl enable docker.service docker.socket, which starts dockerd eagerly at boot (plus its containerd dependency) in every container built on docker/docker-nodejs — whether or not that container ever uses Docker.

This changes it to enable only docker.socket, so dockerd and containerd start lazily on first use of /run/docker.sock. Containers that never touch Docker (e.g. web-IDE / studio workloads) no longer carry an idle dockerd + containerd.

Why this is safe / needs no unit edits

The stock docker.service from Docker's APT package already ships the canonical systemd socket-activation setup:

• ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (binds the inherited socket fd)
• Requires=docker.socket
• Wants=containerd.service / After=... containerd.service

So enabling the socket alone is sufficient — the first client connection starts the service on demand, and docker.service in turn pulls up containerd.

containerd note: containerd ships no .socket unit and cannot be socket-activated on its own (it creates and listens on its own gRPC socket at startup). It doesn't need to be: as a dependency of docker.service it stays stopped until Docker is first used.

Verification

Simulated the change in a running container built from this image (disabled docker.service, left only docker.socket active):

--- boot-time state (only docker.socket active) ---
docker.socket : active
docker.service: inactive
containerd    : inactive

--- after first connection to /run/docker.sock (`docker version`) ---
client 29.6.2 / server 29.6.2
docker.service: active
containerd    : active

dockerd started transparently on the first socket connection and brought containerd up with it.

Impact

• No API/behavior change for consumers — the socket path and docker CLI work identically; the daemon just starts on demand.
• LDAP docker group access (pam_group) is unaffected — the socket unit and docker group are untouched.
• Downstream images (e.g. ozwell-studio, which builds on docker-nodejs) inherit the lazy-start behavior automatically, trimming idle memory/CPU.

[Copilot]

Pull request overview

This PR updates the images/docker base image to rely on systemd socket activation for Docker, aiming to avoid starting dockerd (and containerd) eagerly at boot in downstream containers that never use Docker.

Changes:

• Enable only docker.socket (instead of enabling both docker.service and docker.socket) to support lazy daemon startup.
• Add detailed inline documentation explaining why socket activation is expected to work with stock Docker CE unit files.