feat(local-executor): add opt-in sandbox posture to LocalCommandLineCodeExecutor

[xr843]

Summary

Refs #7462. Supersedes closed #7467.

Adds an explicit three-state sandbox parameter to LocalCommandLineCodeExecutor so callers cannot accidentally rely on an easily-suppressed UserWarning as their only signal that LLM-generated code is running unsandboxed.

sandbox	Behavior
None (default, legacy)	Emits DeprecationWarning and logger.warning(). Execution unchanged — fully backward compatible. In a future release this parameter becomes required.
False	Explicit acknowledgement of unsandboxed execution. Silent — the caller has accepted the risk.
True	Best-effort in-process hardening (details below).

sandbox=True hardening

1. Environment scrub: entries whose name matches credential patterns (TOKEN, SECRET, API_KEY, PASSWORD, PRIVATE_KEY, CREDENTIAL, SESSION, COOKIE, AUTH) are removed from the child process — the most common path by which LLM-generated code exfiltrates provider keys.
2. POSIX rlimits via preexec_fn: RLIMIT_CPU, RLIMIT_AS, RLIMIT_NOFILE, RLIMIT_NPROC cap runaway memory and fork-bomb payloads.
3. Windows degrade path: preexec_fn is unavailable → env scrub applies but a UserWarning directs callers to DockerCommandLineCodeExecutor for strong isolation.

This is NOT a substitute for DockerCommandLineCodeExecutor. The docstring says so verbatim. Adversarial payloads can still read files, call out to the network, and write within work_dir. The opt-in flag exists to:

• move the project off a silent default,
• give enterprise deployments a posture they can certify,
• buy time to design real capability-constrained runtimes (per @polterguy's framing in [Security] LocalCommandLineCodeExecutor executes LLM-generated code without sandboxing #7462).

Backward compatibility

• Constructor signature is additive (sandbox: Optional[bool] = None).
• LocalCommandLineCodeExecutorConfig gains the same field so serialization round-trips the posture — a declarative deployment cannot silently downgrade to the default warning path.
• Existing callers keep working; they just receive a DeprecationWarning with actionable guidance.

Threading to the issue's open questions

• @msaleme Add links to RetrieveChat notebook #1 (explicit parameter at instantiation): covered — sandbox is the gate.
• @msaleme Extact_code can detect single-line code now #2 (telemetry hook): partial — logger.warning() fires every instantiation in the default path. A dedicated telemetry hook could follow as a separate PR if maintainers want it.
• @msaleme OAI_CONFIG_LIST details in documentation #3 (README delta): intentionally not in this PR to keep the diff focused on code + tests. Happy to add in a follow-up once this direction is acked.
• @hanselhansel (compliance-friendly opt-in flag): covered.
• @polterguy (capability-constrained framing): the design explicitly positions this as a posture signal, not a runtime boundary. A proper capability runtime is a bigger design conversation this PR does not try to resolve.

Test plan

Four new tests in test_commandline_code_executor.py:

• test_sandbox_default_emits_deprecation_warning — default path raises DeprecationWarning
• test_sandbox_false_is_silent_opt_out — explicit acknowledgement emits nothing
• test_sandbox_true_strips_credential_env (POSIX-only) — subprocess sees <missing> for MY_API_KEY/SOME_TOKEN, HARMLESS_VAR survives
• test_sandbox_roundtrips_through_config — dump_component / load_component preserve the posture and don't re-trigger the default warning

Local run: pytest tests/code_executors/test_commandline_code_executor.py → 17 passed, 1 skipped (pre-existing venv skip). ruff check, ruff format --check, and mypy all clean on the touched files.

Follow-ups (not in scope here)

• README / docs table contrasting LCE vs Docker (per @msaleme OAI_CONFIG_LIST details in documentation #3).
• Telemetry / SIEM hook for SOC integration (per @msaleme Extact_code can detect single-line code now #2).
• RLIMIT_FSIZE ceiling on work_dir write size.
• Red/Blue harness collaboration with @msaleme once this is merged.

Happy to split this into two PRs (warning upgrade vs. sandbox=True hardening) if maintainers prefer smaller reviews. Drafting so the direction can be sanity-checked before polish on the Windows path.