Add Docker sandbox backend as an alternative to Podman

[mariotrace]

Summary

• Adds DockerSandboxManager/DockerSandbox, implementing the existing
  SandboxManager/SandboxSession protocol via the docker CLI instead of
  podman.
• Docker has no native "pod" concept, so the app and exploit containers are
  connected via --network container:<app>, Docker's equivalent of a shared
  pod network namespace — verified this gives the exploit container
  localhost access to the app container exactly like the Podman pod does.
• Selectable per-config via sandbox.engine: "docker" | "podman"
  (config.py), default remains "podman" — no behavior change for existing
  setups.
• data/config/forge-bedrock.yaml opts into engine: "docker" as an example.

Test plan

• Ran a full pipeline (forge run CVE-2021-44228 --config data/config/forge-bedrock.yaml) end-to-end against the Docker backend:
  app container built, deployed, health-checked; exploit container
  reached the app via the shared network namespace; exploitation
  completed (level 3); containers cleaned up after the run with no
  leftovers.
• CI / maintainer review of the Docker networking approach.

Note: forge-exploit-runner:latest is expected to already exist locally
(built outside this repo, same as for the Podman backend) — this PR doesn't
change how that image is built/sourced.

🤖 Generated with Claude Code

[mariotrace]

I asked Claude Opus to do a review and some local tests. Result below.

---

Review's in. Verdict: the Docker port is solid — no correctness or security bugs in docker.py, and the reviewer actually ran the container lifecycle (build/limits/pod-networking/teardown) live under your local docker→nerdctl alias to confirm it, not just read the code.

Consistency with Podman — the thing you were worried about:

• Shared plumbing (_base.py's _run_container_cli, error-handling patterns, cli.py dispatch) is clean and identical between both backends.
• A few differences exist but are all justified, not drift: Docker skips qualify_dockerfile_images() (Podman needs it for unqualified image names, Docker resolves them natively); Docker removes the exploit container before the app on teardown (required — Docker refuses to remove a container whose netns is still shared, unlike Podman's pod rm -f which cascades). The reviewer verified real Docker enforces this ordering, though the local nerdctl doesn't — so it can't guard the ordering here, just noting for awareness.
• Two low-severity nits: cleanup_stale_containers uses substring name matching vs. Podman's prefix match (functionally fine given current naming), and docstrings/param names still say "pod" for Docker even though Docker has no pod concept (cosmetic).