refactor(devcontainer): migrate from devcontainer to docker compose with DinD

[dimzrio]

What

Replaces the devcontainer setup with a standalone Docker Compose configuration using a Docker-in-Docker sidecar service.

Why

Devcontainer lock-in limits flexibility. Moving to plain Docker Compose allows the environment to run anywhere with Docker, without requiring VS Code devcontainer extension or Codespaces.

How

• Created a Dockerfile based on ubuntu:latest that installs all dev tools (asdf, helm, kubectl, terraform, starship, node, python, etc.)
• Created a docker-compose.yaml with two services: the dev environment container and a docker:dind sidecar
• Removed .devcontainer/ directory and its lock file

The dev container connects to the DinD service via DOCKER_HOST=tcp://docker:2375 over a private bridge network.

Changes

• Dockerfile (new) — Image with all tools from .tool-versions installed via asdf, plus Docker CLI, Node.js LTS, Python, Go Task, Helm plugins, starship, yj/yq, and dotfiles stow
• docker-compose.yaml (new) — Two-service stack: devcontainer (build env) + docker (DinD sidecar, privileged, with persisted docker-data volume)
• .devcontainer/ (removed) — No longer needed

Commits

• refactor(devcontainer): migrate from devcontainer to docker compose with DinD (cb07f13)

Testing

• Build the image: docker compose build
• Start the stack: docker compose up -d
• Verify Docker: docker compose exec devcontainer docker ps
• Verify tools: docker compose exec devcontainer asdf list
• Clean up: docker compose down

Notes

• The DinD service runs in privileged mode, which is standard for Docker-in-Docker setups
• Docker images/layers are persisted in the docker-data volume across container restarts
• VS Code Dev Container extension will no longer auto-launch the environment — use docker compose run --rm devcontainer directly
• VS Code extensions (SOPS, opencode) should be installed manually in your editor