Fail closed when the container runner sandbox is unavailable

[DeveloperDurp]

Motivation

• Prevent deployment steps from running with access to the database or secret material when the runtime/container profile lacks the privileges required for the documented runner sandbox.
• The current behavior fell back to un-chrooted execution when bind-mount or runner-account setup failed, exposing the DB and AES key to step scripts.

Description

• Add a small isolated(chrooted bool) bool helper to Sandbox on Linux and the non-Linux stub to express whether both credential-dropping and chroot isolation are active via s.enabled && chrooted or false respectively.
• In runStepAttempt (internal/runner/runner.go) return an error when DURPDEPLOY_REQUIRE_SANDBOX=1 and r.sandbox.isolated(chrooted) is false, causing the runner to fail closed rather than fall back to un-chrooted execution.
• Enable strict (fail-closed) sandbox mode by setting DURPDEPLOY_REQUIRE_SANDBOX: "1" in the default compose.yml and the Helm pod env in charts/durpdeploy/templates/deployment.yaml so container deployments that lack required capabilities refuse to run step scripts.
• Preserve permissive behavior for installs that do not opt into strict mode by gating the change behind the DURPDEPLOY_REQUIRE_SANDBOX env variable.

Testing

• Ran formatting and quick checks with gofmt -w internal/runner/*.go and git diff --check, which reported no diffs or issues.
• Exercised the runner package with go test ./internal/runner and ran go vet ./internal/runner, which completed without errors.
• Attempts to run the full test suite (go test ./...) and regenerate templ assets (templ generate) were blocked because generated *_templ.go and static/swagger-ui/ assets are missing and the environment could not download the templ tool, so full integration tests could not be completed here.

---

Codex Task