fix(skills): make env_passthrough registrations visible across tool context snapshots

[liuhao1024]

What does this PR do?

Fixes #90004: a skill's declared env vars (required_environment_variables and the legacy prerequisites.env_vars) never reached execute_code/terminal, on any turn or session — only manually adding the var to terminal.env_passthrough in config.yaml worked.

Mechanism. skill_view registers the skill's vars into the sandbox passthrough allowlist, which was backed by a ContextVar. Tool dispatch fans each tool call onto a worker whose context is a copy_context() snapshot taken at submit time (tools.thread_context.propagate_context_to_thread). The registration therefore lived and died inside the skill_view worker's snapshot:

• the submitting thread's context never saw it (a ContextVar.set in a copied context cannot reach the parent), and
• the next tool's submit-time snapshot (execute_code, terminal) always started from an empty allowlist.

So the failure was deterministic, which matches the report exactly (consistent across fresh sessions; restart doesn't help). The config-based allowlist (terminal.env_passthrough) is a module-level global — that visibility difference is precisely why the manual workaround worked. I reproduced the invisibility in isolation on unmodified main (register inside a copied context, then a sibling snapshot sees False).

Fix. Store the skill-registered names in a process-wide set, matching the config path's visibility. Cross-session exposure is limited to the names: values still resolve per profile through resolve_passthrough_value's secret_scope, so a name registered by one session cannot read another profile's secret. clear_env_passthrough keeps its reset semantics; a later skill_view re-registers on demand.

This un-breaks at least the 4 bundled skills the report lists as using the legacy key (notion, airtable, gif-search, teams-meeting-pipeline) — and equally affects skills using the modern required_environment_variables key, since both feed the same registration call.

Related Issue

Fixes #90004

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• tools/env_passthrough.py: the skill-registration allowlist moves from a ContextVar-backed set to a process-wide module-level set (_get_allowed returns it; register_env_passthrough mutates it in place; clear_env_passthrough clears it). The unused ContextVar import is dropped; comments document why process-wide visibility is required by the tool-dispatch snapshot model and what the exposure boundary is.

How to Test

1. pytest tests/tools/test_env_passthrough.py -q — 25 passed (2 new tests).
2. Fail-on-main verified for the core scenario: test_registration_in_copied_context_is_visible_to_sibling_snapshot runs the register-then-check sequence inside a pristine context (so the fixture's current-context initialization cannot mask the bug) — it fails on unmodified main and passes with the fix.
3. tests/tools/test_skill_env_passthrough.py + tests/tools/test_local_env_blocklist.py: 104 passed, 2 skipped — the provider-credential blocklist (GHSA-rhgp-j443-p4rf) and profile-scope semantics are unchanged.
4. tests/tools/test_code_execution*.py: 98 passed, 3 skipped; the single interrupt-handling failure reproduces identically on unmodified main (pre-existing, unrelated).

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 15 (arm64)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A

[liuhao1024]

The failing checks here are a pre-existing main regression, not caused by this diff: the failing test is the FAL catalog all-off upscale invariant (test_upscale_defaults_are_all_off), which was broken on upstream/main itself for a window on Aug 19 (a catalog entry shipped upscale: True against the opt-in-only policy the test pins). The same failure hit sibling PRs from that window and was root-caused on #89968/#89987.

Main has since resolved it on its own (the catalog entry was fixed and the invariant test was dropped in 00888e8), so this failure should disappear on the next rebase. This PR's changes don't touch the image-generation catalog or its tests. Not re-running CI since the failing slice is unrelated to the change under review.