fix: resolve passthrough env vars through secret scope under multiplexing

[JonthanaHanh]

Summary

Under gateway.multiplex_profiles, terminal and execute_code environments are built from os.environ directly, bypassing the active profile secret scope. This causes routed profiles to receive the default profile's credentials for any key configured via terminal.env_passthrough.

Since the default profile is typically the broadest, every narrower profile is silently promoted to its authority. The call succeeds with the wrong credentials, and nothing logs the mismatch — it fails open.

Changes

• tools/environments/local.py::_make_run_env: After building the subprocess env, re-resolve passthrough keys through get_secret() when a profile secret scope is active.
• tools/environments/docker.py::_build_init_env_args: Same treatment for Docker forwarded env keys.

When no scope is installed (single-profile deployment), behavior is unchanged — get_secret() falls through to os.environ transparently.

Test Plan

• tests/agent/test_secret_scope.py — 12 passed
• tests/tools/test_local_env_blocklist.py — 30 passed
• tests/tools/test_env_passthrough.py — 24 passed
• Syntax check on both modified files

Fixes #76163

[teknium1]

Thanks for tracing the multiplex secret-scope gap; current main does have the reported raw-environment reads in tools/environments/local.py:1226 and tools/environments/docker.py:1525.

Problems

• In the added local branch, a scope miss leaves the old run_env[k] value intact. Under multiplexing, get_secret() returns None for a missing scoped key rather than reading os.environ (agent/secret_scope.py:150-156), so this still forwards the default-profile credential.
• The stated execute_code coverage is not implemented: tools/code_execution_tool.py:1371 still calls _scrub_child_env(os.environ), and its passthrough branch copies the raw value at :240-243. Background/PTY terminal launches similarly use _sanitize_subprocess_env(os.environ, ...) in tools/process_registry.py:735,777.
• The PR diff contains no regression tests for the two-profile and scoped-missing cases.

Suggested changes

• Centralize scope-aware passthrough resolution for all four child-environment paths; omit a key on a scoped miss and let unscoped multiplex reads fail closed.
• Add behavioral tests proving routed-profile selection and no fallback to the default profile.

Automated hermes-sweeper review.

[teknium1]

A scope miss leaves the existing run_env[k] value from os.environ intact. In multiplex mode get_secret() returns None for an absent scoped key (agent/secret_scope.py:150-156), so this still forwards the default-profile credential. Remove/omit the key on a scope miss, and avoid bypassing get_secret() when multiplexing is active so unscoped reads fail closed.

[teknium1]

Closing in favor of #76213, which implements the same fix correctly. The diagnosis here (passthrough vars resolve from the default profile's environ under multiplexing) is right — thanks for surfacing it. But the implementation has three lens violations our review flagged: on a scoped miss the pre-populated default-profile value stays in run_env (the exact leak this targets), the except-Exception blocks swallow UnscopedSecretError (fail-closed must propagate), and only 2 of 4 child-env paths are covered (code_execution_tool + process_registry untouched), with no regression tests. #76213 centralizes resolution in resolve_passthrough_value, covers all four paths, handles scope-change staleness, and ships two-profile tests. Thanks @JonthanaHanh.