codex-tools: extract dynamic tool adapters

[bolinfest]

Why

codex-tools already owned the shared JSON schema parser and the MCP tool schema adapter, but core/src/tools/spec.rs still parsed dynamic tools directly.

That left the tool-schema boundary split in two different ways:

• MCP tools flowed through codex-tools, while dynamic tools were still parsed in codex-core
• the extracted dynamic-tool path initially introduced a dynamic-specific parsed shape even though codex-tools already had very similar MCP adapter output

This change finishes that extraction boundary in one step. codex-core still owns ResponsesApiTool assembly, but both MCP tools and dynamic tools now enter that layer through codex-tools using the same parsed tool-definition shape.

What changed

• added tools/src/dynamic_tool.rs and sibling tools/src/dynamic_tool_tests.rs
• introduced parse_dynamic_tool() in codex-tools and switched core/src/tools/spec.rs to use it for dynamic tools
• added tools/src/parsed_tool_definition.rs so both MCP and dynamic adapters return the same ParsedToolDefinition
• updated core/src/tools/spec.rs to build ResponsesApiTool through a shared local adapter helper instead of separate MCP and dynamic assembly paths
• expanded core/src/tools/spec_tests.rs so the dynamic-tool adapter test asserts the full converted ResponsesApiTool, including defer_loading
• updated codex-rs/tools/README.md to reflect the shared parsed tool-definition boundary

Test plan

• cargo test -p codex-tools
• cargo test -p codex-core --lib tools::spec::

---

Stack created with Sapling. Best reviewed with ReviewStack.

• codex-tools: introduce named tool definitions #15953
• -> codex-tools: extract dynamic tool adapters #15944