code-mode: carry nested tool kind through runtime

[pakrym-oai]

Why

Code mode only used nested spec lookup at execution time to rediscover whether a nested tool should be invoked as a function tool or a freeform tool.

That information is already present in the enabled tool metadata that code mode builds to expose tools.* and ALL_TOOLS, so re-looking it up from the router was redundant and kept execution coupled to a separate spec lookup path.

What Changed

• thread CodeModeToolKind through the code-mode runtime ToolCall event and CodeModeNestedToolCall
• emit the nested tool kind directly from the V8 callback using the already-enabled tool metadata
• build nested tool payloads from the propagated kind instead of calling find_spec
• remove the now-unused find_spec plumbing from the router and parallel runtime helpers
• add unit coverage for function vs freeform payload shaping and update affected router tests

Testing

• cargo test -p codex-code-mode
• cargo test -p codex-core code_mode::tests
• cargo test -p codex-core extension_tool_bundles_are_model_visible_and_dispatchable
• cargo test -p codex-core model_visible_specs_filter_deferred_dynamic_tools