Extract update_plan tool spec into codex-tools (#16481)

## Why

`codex-rs/core/src/tools/handlers/plan.rs` still owned both the
`update_plan` runtime handler and the static tool definition. The tool
definition is pure metadata, so keeping it in `codex-core` works against
the ongoing effort to move tool-spec code into `codex-tools` and keep
`codex-core` focused on orchestration and execution paths.

This continues the extraction work from #16379, #16471, and #16477.

## What Changed

- added `codex-rs/tools/src/plan_tool.rs` with
`create_update_plan_tool()`
- re-exported that constructor from `codex-rs/tools/src/lib.rs`
- updated `codex-rs/core/src/tools/spec.rs` and
`codex-rs/core/src/tools/spec_tests.rs` to use the `codex-tools` export
instead of a core-local static
- removed the old `PLAN_TOOL` definition from
`codex-rs/core/src/tools/handlers/plan.rs`; the `PlanHandler` runtime
logic still stays in `codex-core`
- tightened two `codex-core` aliases to `#[cfg(test)]` now that
production code no longer needs them

## Testing

- `cargo test -p codex-tools`
- `cargo test -p codex-core tools::spec::tests`

---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16481).
* #16482
* __->__ #16481

codex-rs/tools/src/lib.rs

@@ -12,6 +12,7 @@ mod json_schema;
 mod local_tool;
 mod mcp_resource_tool;
 mod mcp_tool;
+mod plan_tool;
 mod request_user_input_tool;
 mod responses_api;
 mod tool_config;
@@ -64,6 +65,7 @@ pub use mcp_resource_tool::create_list_mcp_resources_tool;
 pub use mcp_resource_tool::create_read_mcp_resource_tool;
 pub use mcp_tool::mcp_call_tool_result_output_schema;
 pub use mcp_tool::parse_mcp_tool;
+pub use plan_tool::create_update_plan_tool;
 pub use request_user_input_tool::create_request_user_input_tool;
 pub use request_user_input_tool::request_user_input_tool_description;
 pub use request_user_input_tool::request_user_input_unavailable_message;

codex-rs/tools/src/plan_tool.rs

@@ -0,0 +1,51 @@
+use crate::JsonSchema;
+use crate::ResponsesApiTool;
+use crate::ToolSpec;
+use std::collections::BTreeMap;
+
+pub fn create_update_plan_tool() -> ToolSpec {
+    let plan_item_properties = BTreeMap::from([
+        ("step".to_string(), JsonSchema::String { description: None }),
+        (
+            "status".to_string(),
+            JsonSchema::String {
+                description: Some("One of: pending, in_progress, completed".to_string()),
+            },
+        ),
+    ]);
+
+    let properties = BTreeMap::from([
+        (
+            "explanation".to_string(),
+            JsonSchema::String { description: None },
+        ),
+        (
+            "plan".to_string(),
+            JsonSchema::Array {
+                description: Some("The list of steps".to_string()),
+                items: Box::new(JsonSchema::Object {
+                    properties: plan_item_properties,
+                    required: Some(vec!["step".to_string(), "status".to_string()]),
+                    additional_properties: Some(false.into()),
+                }),
+            },
+        ),
+    ]);
+
+    ToolSpec::Function(ResponsesApiTool {
+        name: "update_plan".to_string(),
+        description: r#"Updates the task plan.
+Provide an optional explanation and a list of plan items, each with a step and status.
+At most one step can be in_progress at a time.
+"#
+        .to_string(),
+        strict: false,
+        defer_loading: None,
+        parameters: JsonSchema::Object {
+            properties,
+            required: Some(vec!["plan".to_string()]),
+            additional_properties: Some(false.into()),
+        },
+        output_schema: None,
+    })
+}