fix(runtime): skip non-UTF-8 environment variables instead of panicking

[twtrubiks]

Summary

• claw panics on startup (claw, claw doctor, ...) whenever any environment variable holds a non-UTF-8 value:

  thread 'main' panicked at library/std/src/env.rs:168:83:
  called `Result::unwrap()` on an `Err` value: "/hom…"
  

• std::env::vars() panics on non-UTF-8 values. A common real-world trigger: interactive zsh (the macOS default shell) exports a "metafied", non-UTF-8 $_ when a command is run by relative path from a directory containing non-ASCII characters. Following the README (cd rust && ./target/debug/claw) in a checkout under e.g. ~/下載/ (any CJK path) crashes immediately.
• Fix: the three env::vars() snapshots in the runtime (container detection in sandbox.rs, RemoteSessionContext::from_env and UpstreamProxyBootstrap::from_env in remote.rs) now use env::vars_os() and skip entries whose key or value is not valid UTF-8.

Anti-slop triage

• Classification: actionable-fix
• Evidence: repro below; new integration test doctor_tolerates_non_utf8_environment_values (unix-only) fails without the fix.
• Non-destructive review result: merge candidate

Reproduction

In interactive zsh, from a checkout whose path contains non-ASCII characters:

cd ~/下載/claw-code/rust
./target/debug/claw doctor   # panics; zsh exports $_ as /home/user/\xe4\xb8\x83\xab.../claw

Or from any shell, by setting a non-UTF-8 value directly:

bash -c 'env "_=$(printf "/tmp/\xe4\xb8\x83\xab")" ./target/debug/claw doctor'

Verification

• cargo fmt --all --check
• cargo test --workspace: all pass except tools::tests::powershell_runs_via_stub_shell, which fails locally only because pwsh is not installed (same on main).
• cargo clippy --workspace: no new warnings in the touched files.
• Manual: ./target/debug/claw doctor from a CJK path in interactive zsh no longer panics.
• Targeted tests/docs checks ran, or the gap is explicitly recorded.
• git diff --check passes.
• No live secrets, tokens, private logs, or unrelated generated churn are included.

Compatibility and known gaps

• Non-UTF-8 environment variables are now ignored by container detection and remote/proxy bootstrap instead of crashing the process. Those code paths only look up well-known ASCII variable names, so behavior is otherwise unchanged.
• The regression test is #[cfg(unix)] because it builds a non-UTF-8 OsStr from raw bytes; Windows behavior is unchanged.

Resolution gate

• If this PR resolves an issue, the issue number and fix evidence are linked. (No existing issue; evidence is in this PR.)
• If this PR should not merge, the rejection/defer rationale is evidence-backed and does not rely on vibes.
• I did not merge/close remote PRs or issues from an automation lane without owner approval.

[XinwangTao]

Good fix — this is a real startup crash for anyone running from a non-ASCII path with zsh (the metafied $_ case is common enough to matter). Switching the three runtime snapshots to vars_os() and skipping invalid UTF-8 entries is the right call, and the doctor_tolerates_non_utf8_environment_values integration test pins the regression.

[XinwangTao]

这个修复很实际：在含 CJK 字符的路径下运行 claw，zsh 导出的非 UTF-8 $_ 会让启动直接 panic，对中文用户来说是相当常见的崩溃场景。改用 env::vars_os() 并跳过非法 UTF-8 条目是正确做法——这三处只查已知的 ASCII 变量名，跳过非 UTF-8 值不会改变行为，还避免了进程直接崩溃。新增的 unix-only 回归测试也覆盖了根因，支持合并。

[XinwangTao]

这个修复很实际：在含 CJK 字符的路径下运行 claw，zsh 导出的非 UTF-8 $_ 会让启动直接 panic，对中文用户来说是相当常见的崩溃场景。改用 env::vars_os() 并跳过非法 UTF-8 条目是正确做法——这三处只查已知的 ASCII 变量名，跳过非 UTF-8 值不会改变行为，还避免了进程直接崩溃。新增的 unix-only 回归测试也覆盖了根因，支持合并。