[codex] Move tool specs onto handlers (#21461)

## Why

This is the next stacked step after deleting the tool-handler kind
indirection. Specs should come from the registered handlers themselves
so registry construction has a single source of truth for handler
behavior and exposed tool definitions.

## What changed

- Added `ToolHandler::spec()` plus handler-provided parallel/code-mode
metadata, and made `ToolRegistryBuilder::register_handler` automatically
collect specs from registered handlers.
- Moved builtin tool spec construction into the corresponding handlers
and their adjacent `_spec` modules, including shell, unified exec, apply
patch, view image, request plugin install, tool search, MCP resource,
goals, planning, permissions, agent jobs, and multi-agent tools.
- Reworked configurable handlers to receive their tool-building options
through constructors, with non-optional handler options where the
handler is always spec-backed. Shell fallback handlers keep an explicit
no-spec mode because they are also registered as hidden dispatch
aliases.
- Kept `CodeModeExecuteHandler` on the explicit configured wrapper so
the code-mode exec spec can still be built from the nested registry.

## Verification

- `cargo check -p codex-core`
- `cargo test -p codex-core tools::spec_plan::tests`
- `cargo test -p codex-core tools::spec::tests`
- `cargo test -p codex-core tools::handlers::multi_agents_spec::tests`
- `RUST_MIN_STACK=16777216 cargo test -p codex-core
tools::handlers::multi_agents::tests`
- `cargo test -p codex-core tools::handlers::apply_patch::tests`
- `cargo test -p codex-core tools::handlers::unified_exec::tests`
- `just fix -p codex-core`
- `git diff --check`

codex-rs/core/src/tools/code_mode/execute_handler.rs

@@ -5,6 +5,7 @@ use crate::tools::context::ToolPayload;
 use crate::tools::registry::ToolHandler;
 use crate::tools::registry::ToolKind;
 use codex_tools::ToolName;
+use codex_tools::ToolSpec;
 
 use super::ExecContext;
 use super::PUBLIC_TOOL_NAME;
@@ -12,9 +13,15 @@ use super::build_enabled_tools;
 use super::handle_runtime_response;
 use super::is_exec_tool_name;
 
-pub struct CodeModeExecuteHandler;
+pub struct CodeModeExecuteHandler {
+    spec: ToolSpec,
+}
 
 impl CodeModeExecuteHandler {
+    pub(crate) fn new(spec: ToolSpec) -> Self {
+        Self { spec }
+    }
+
     async fn execute(
         &self,
         session: std::sync::Arc<crate::session::session::Session>,
@@ -83,6 +90,10 @@ impl ToolHandler for CodeModeExecuteHandler {
         ToolName::plain(PUBLIC_TOOL_NAME)
     }
 
+    fn spec(&self) -> Option<ToolSpec> {
+        Some(self.spec.clone())
+    }
+
     fn kind(&self) -> ToolKind {
         ToolKind::Function
     }

codex-rs/core/src/tools/code_mode/wait_handler.rs

@@ -7,11 +7,13 @@ use crate::tools::context::ToolPayload;
 use crate::tools::registry::ToolHandler;
 use crate::tools::registry::ToolKind;
 use codex_tools::ToolName;
+use codex_tools::ToolSpec;
 
 use super::DEFAULT_WAIT_YIELD_TIME_MS;
 use super::ExecContext;
 use super::WAIT_TOOL_NAME;
 use super::handle_runtime_response;
+use super::wait_spec::create_wait_tool;
 
 pub struct CodeModeWaitHandler;
 
@@ -46,6 +48,10 @@ impl ToolHandler for CodeModeWaitHandler {
         ToolName::plain(WAIT_TOOL_NAME)
     }
 
+    fn spec(&self) -> Option<ToolSpec> {
+        Some(create_wait_tool())
+    }
+
     fn kind(&self) -> ToolKind {
         ToolKind::Function
     }