Why

Extension tools were split across two public runtime contracts: codex-tool-api exposed ToolBundle plus its own call/spec/error types, while core native tools used codex_tools::ToolExecutor. That made contributed tool specs and execution behavior easy to drift apart and added another crate boundary for what should be one executable-tool seam.

This PR makes ToolExecutor the single runtime contract and keeps extension-specific pinning in codex-extension-api.

Remaining todo

https://github.com/openai/codex/pull/22369/changes#diff-b935ea8245c3ce568a30cff660175fa6390b66b872ae409e1e2e965738250741R5
Either generic Invocation or sub-extract the ToolCall and clean ToolInvocation

What changed

• Removed the codex-tool-api workspace crate and its dependencies from core and codex-extension-api.
• Made codex_tools::ToolExecutor object-safe with async_trait so extension contributors can return a dyn executor.
• Added the extension-facing aliases under ext/extension-api/src/contributors/tools.rs, including ExtensionToolExecutor = dyn ToolExecutor<ToolCall, Output = ExtensionToolOutput>.
• Changed ToolContributor::tools to return extension executors directly instead of ToolBundles.
• Updated core’s extension tool handler/registry/router path to adapt those extension executors into the existing native ToolInvocation runtime path.
• Added focused coverage for extension tools being registered, model-visible, dispatchable, and not replacing built-in tools.

Verification

• cargo test -p codex-tools
• cargo test -p codex-extension-api