codex-tools: extract tool spec models

[bolinfest]

Why

This continues the codex-tools migration by moving another passive tool-definition layer out of codex-core.

After ResponsesApiTool and the lower-level schema adapters moved into codex-tools, core/src/client_common.rs was still owning ToolSpec and the web-search request wire types even though they are serialized data models rather than runtime orchestration. Keeping those types in codex-core makes the crate boundary look smaller than it really is and leaves non-runtime tool-shape code coupled to core.

What changed

• moved ToolSpec, ResponsesApiWebSearchFilters, and ResponsesApiWebSearchUserLocation into codex-rs/tools/src/tool_spec.rs
• added focused unit tests in codex-rs/tools/src/tool_spec_tests.rs for:
  • ToolSpec::name()
  • web-search config conversions
  • ToolSpec serialization for web_search and tool_search
• kept codex-rs/tools/src/lib.rs exports-only by re-exporting the new module from lib.rs
• reduced core/src/client_common.rs to a compatibility shim that re-exports the extracted tool-spec types for current core call sites
• updated core/src/tools/spec_tests.rs to consume the extracted web-search types directly from codex-tools
• updated codex-rs/tools/README.md so the crate contract reflects that codex-tools now owns the passive tool-spec request models in addition to the lower-level Responses API structs

Test plan

• cargo test -p codex-tools
• cargo test -p codex-core --lib tools::spec::
• cargo test -p codex-core --lib client_common::
• just fix -p codex-tools -p codex-core
• just argument-comment-lint

References

• codex-tools: extract shared tool schema parsing #15923
• codex-tools: extract MCP schema adapters #15928
• codex-tools: extract dynamic tool adapters #15944
• codex-tools: introduce named tool definitions #15953
• codex-tools: extract responses API tool models #16031