…proval

A Dockerfile.odek in the working directory was built automatically with no
approval gate, while the analogous sandbox_image/sandbox_env project-config
knobs correctly require explicit operator approval. docker build executes
the repo-controlled Dockerfile's RUN instructions outside the sandbox threat
model (default capabilities, entire working directory readable as build
context), so merely running odek inside a malicious repository - including
odek serve, which sandboxes by default - granted host-adjacent code
execution and workspace exfiltration.

Changes:

- approveProjectSandbox now also requires approval for an implicit
  Dockerfile.odek build (sandbox active, no explicit image, file present).
  The approval is keyed on the Dockerfile content hash, so editing the file
  invalidates a prior "trust this project" approval. The prompt warns that
  building runs repo-controlled code with the whole working directory as
  build context.
- setupSandbox enforces the approval non-interactively at build time
  (env bypass, persisted trust, or in-process session approval), closing
  the gap where a Dockerfile appears or changes after startup - e.g. a
  serve-mode sandbox created per WebSocket connection, or a session
  continuation that re-enables the sandbox.
- continueCmd now calls approveProjectSandbox like every other command;
  previously odek continue applied project sandbox overrides without any
  approval at all.
- docker build runs with --network=none by default so RUN steps cannot
  fetch attacker payloads or exfiltrate build-context data over the
  network; ODEK_SANDBOX_BUILD_NETWORK=1 (operator-only) opts back in for
  legitimate networked builds such as RUN apk add.

Regression tests cover the requirement detection, non-TTY fail-closed
behavior, env bypass, once-vs-trust semantics, content-change invalidation
at both gates, build-time enforcement, and the --network=none default.
Docs updated: SANDBOXING.md, SECURITY.md (new section 18b), CONFIG.md,
AGENTS.md.