devcontainer pipeline: replace builder.go with devcontainers-cli integration

[Gandalf-Le-Dev]

Sub-project (1) of #12.

Scope

Replace `internal/containers/builder.go`'s hand-rolled Dockerfile generator with a devcontainer-cli-driven pipeline. Hopbox produces a `devcontainer.json` (somewhere — TBD in brainstorm) and a build pipeline that yields an OCI image tagged per-user.

What changes

• `builder.go` no longer emits Dockerfile RUN lines per tool.
• Per-user image built via `devcontainers/cli build` or equivalent (decide in design): inputs are base image + features + options; output is per-user OCI image.
• Sysbox runtime still enforced at runtime.
• Multi-arch handled by the features, not by hopbox.

Out of scope

• Feature authoring (goes to sub-project (2)).
• Wizard UI (sub-project (4)).
• Policy allowlist enforcement (sub-project (3)) — just a hook here, real logic there.
• Profile.toml removal (sub-project (5)).

Success criteria

• Given a minimal `devcontainer.json` (features: [] + base image), hopbox builds a container that behaves like today's default box.
• Given one or more features selected, hopbox builds a container with those features installed, USER handling correct (no manual root/dev dance in hopbox code).
• Build time comparable to today's bespoke path (±20% acceptable).
• All existing `cmd/hop` + `internal/gateway` integration preserved (entry shell, exec, resize, cancellation from Handle SIGWINCH cleanly #3, link codes).

Risks

• `@devcontainers/cli` is Node.js. Must live somewhere: bundled into hopboxd host, sidecar image, or reimplement a minimal resolver in Go.
• Devcontainer features may assume layouts hopbox doesn't provide (e.g., `/etc/profile.d` expectations). Audit community features we'd rely on.
• Per-user image tagging + cache invalidation needs to account for feature-hash the same way today's Profile.Hash does.

Brainstorm + design to land as `docs/superpowers/specs/YYYY-MM-DD-devcontainer-build-pipeline-design.md`.