feat: make ToolExecutor an async trait

[jif-oai]

Why

codex_tools::ToolExecutor keeps a tool spec attached to its runtime handler, but extension tools still carried a parallel ExtensionToolFuture / ExtensionToolExecutor shape. That made extension-owned tools look different from host tools even though routing, registration, and execution need the same abstraction.

This PR makes the shared executor contract directly async and lets extension tools implement it too, so host tools and extension tools can move through the same registration path.

What changed

• Changed ToolExecutor::handle to an async fn using async-trait, and updated built-in tool handlers to implement the async trait directly.
• Replaced the bespoke ExtensionToolFuture contract with a marker ExtensionToolExecutor over ToolExecutor<ToolCall, Output = JsonToolOutput>, re-exporting ToolExecutor from codex-extension-api.
• Updated the memories extension tools to implement the shared executor trait.
• Split tool-router construction into collected executors plus hosted model specs, keeping hosted tools like web search and image generation separate from executable handlers.
• Updated spec/router tests and extension-tool stubs for the new executor shape.

Verification

• Not run locally.

[jif-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a5c6c5b5b3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".