Simplify tool executor and registry plumbing

[jif-oai]

Why

The tool runtime path still had a typed output associated type on ToolExecutor, plus a core-only RegisteredTool adapter and extension-only executor aliases. That made every new shared tool runtime carry extra adapter plumbing before it could participate in core dispatch, extension tools, hook payloads, telemetry, and model-visible spec generation.

This PR moves output erasure to the shared executor boundary so core and extension tools can use the same execution contract directly.

What Changed

• Changed codex_tools::ToolExecutor to return Box<dyn ToolOutput> instead of an associated Output type.
• Removed the extension-specific ExtensionToolExecutor / ExtensionToolOutput aliases and exposed ToolExecutor<ToolCall> plus ToolOutput through codex-extension-api.
• Reworked core tool registration around CoreToolRuntime and ToolRegistry::from_tools, removing the extra RegisteredTool / ToolRegistryBuilder layer.
• Consolidated model-visible spec planning and registry construction in core/src/tools/spec_plan.rs, including deferred tool search and code-mode-only filtering.
• Added ToolOutput helpers for post-tool-use hook ids and inputs so MCP, unified exec, extension, and other boxed outputs preserve the same hook payload behavior.
• Updated core handlers, memories tools, and the related registry/spec/router tests to use the simplified contract.

Test Coverage

• Updated coverage for tool spec planning, registry lookup, deferred tool search registration, extension tool routing, post-tool-use hook payloads, dispatch tracing, guardian output extraction, and memories extension tool execution.

[jif-oai]

@codex review