Extract code-mode nested tool collection into codex-tools (#16509)

## Why
This is another small step in the `codex-core` -> `codex-tools`
migration described in `AGENTS.md`.

`core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs` were both
hand-rolling the same pure transformation: convert visible `ToolSpec`s
into code-mode nested tool definitions, then sort and deduplicate by
tool name. That logic does not depend on core runtime state or handlers,
so keeping it in `codex-core` makes `spec.rs` harder to peel out later
than it needs to be.

## What Changed
- Add `collect_code_mode_tool_definitions()` to
`codex-rs/tools/src/code_mode.rs`.
- Reuse that helper from `codex-rs/core/src/tools/spec.rs` when
assembling the `exec` tool description.
- Reuse the same helper from `codex-rs/core/src/tools/code_mode/mod.rs`
when exposing nested tool metadata to the code-mode runtime.

This is intended to be a straight refactor with no behavior change and
no new test surface.

## Verification
- `cargo test -p codex-tools`
- `cargo test -p codex-core tools::spec::tests`
- `cargo test -p codex-core code_mode_only_`

codex-rs/tools/src/code_mode.rs

@@ -37,6 +37,18 @@ pub fn tool_spec_to_code_mode_tool_definition(spec: &ToolSpec) -> Option<CodeMod
         .then(|| codex_code_mode::augment_tool_definition(definition))
 }
 
+pub fn collect_code_mode_tool_definitions<'a>(
+    specs: impl IntoIterator<Item = &'a ToolSpec>,
+) -> Vec<CodeModeToolDefinition> {
+    let mut tool_definitions = specs
+        .into_iter()
+        .filter_map(tool_spec_to_code_mode_tool_definition)
+        .collect::<Vec<_>>();
+    tool_definitions.sort_by(|left, right| left.name.cmp(&right.name));
+    tool_definitions.dedup_by(|left, right| left.name == right.name);
+    tool_definitions
+}
+
 pub fn create_wait_tool() -> ToolSpec {
     let properties = BTreeMap::from([
         (