core: use current step environments for tools

[sayan-oai]

Why

With deferred executors, an environment can become ready between two sampling requests in the same turn. The model-visible environment update, advertised tools, and eventual tool execution must all describe the same request-time view.

Otherwise, a request built while only environment B is ready can advertise a tool without an environment_id; if higher-priority environment A becomes ready before execution, that call could silently run in A instead.

This PR is stacked on #29527.

Design

run_turn captures one Arc<StepContext> at each sampling-request boundary. That step owns the request's TurnContext and environment snapshot.

• World-state environment updates and tool planning borrow that same step.
• ToolCallRuntime retains the Arc while asynchronous tool calls execute.
• ToolInvocation carries the step to handlers; its temporary turn compatibility field is derived from the same object.
• ToolRouter does not retain StepContext; it only uses it while constructing the request's tool set.
• With DeferredExecutor disabled, step capture keeps using the environments frozen at turn start.

Simply: every sampling request gets one consistent picture of its environments, from what the model sees through where its tool calls run.

What changed

• Build environment-dependent tool specs from the current request's StepContext.
• Use that same step for unified exec, legacy shell, apply_patch, view_image, and request_permissions execution.
• Hide environment-backed tools, including request_permissions, while no environment is attached.
• Resolve legacy shell paths and metadata from the selected step environment instead of the stale turn-start environment.
• Capture explicit steps at non-turn-loop boundaries such as compaction, prompt debug, and startup prewarm.
• Reconcile prompt-debug history from the same step used to build its tools.

Follow-up

• Bind yielded code-mode cells to the tool runtime that created them, so nested calls made after yielding continue to use the originating request's StepContext.

Test plan

• just test -p codex-core deferred_executor_updates_context_and_tools_after_startup
• just test -p codex-core environment_count_controls_environment_backed_tools
• just test -p codex-core build_prompt_input_includes_context_and_user_message

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 26c11ecd14

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[sayan-oai]

@codex review this

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: 3be0e765e3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[sayan-oai]

@codex review this

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Swish!

Reviewed commit: 3cd0872bf6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".