Code Mode: support function-backed `exec` for providers without custom/freeform tool support

Supporting note from the tool layer: the infrastructure for a dual transport already exists — the registry treats ToolSpec::Function and ToolSpec::Freeform uniformly (they share the default-namespace path in spec_plan.rs), and Code Mode's payload construction is already kind-dispatched (CodeModeToolKind::Freeform => build_freeform_tool_payload(...) — https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/core/src/tools/code_mode/mod.rs#L386). So "function-backed exec" is: pick the spec kind per model capability at registration time (freeform when the model advertises custom-tool support, else a Function spec with one required string property, e.g. {"javascript": "..."}), and accept the function-payload variant in the execute handler where it currently matches only the custom payload. The Code Mode runtime behind the handler is untouched, which is exactly the "no second runtime" property you want.

One wrinkle worth deciding explicitly: with a function transport the JS arrives JSON-escaped, which costs tokens and invites escaping mistakes from weaker models — so keeping freeform as the preferred transport where supported (capability-based selection, not a global switch) is the right default. And the current failure mode ("Unsupported custom tool: 'exec'") should become that fallback rather than an error — it's another case of a capability mismatch surfacing as a hard stop when a degraded-but-working path exists.

POC update: the proposed function-backed exec transport works end-to-end.

I implemented a local, uncommitted POC with the following shape:

• add a custom_tools provider capability;
• expose Code Mode exec as the existing freeform tool when supported;
• otherwise expose it as a strict function tool with one required string property, code;
• normalize both ToolPayload::Custom and ToolPayload::Function at the existing handler boundary;
• keep the V8 runtime and nested tool routing unchanged.

The function form is:

{
  "type": "function",
  "name": "exec",
  "parameters": {
    "type": "object",
    "properties": {
      "code": { "type": "string" }
    },
    "required": ["code"],
    "additionalProperties": false
  },
  "strict": true
}

Validation completed:

• provider capability selection;
• function schema generation;
• function payload parsing;
• regression coverage for the existing freeform path;
• integration test proving that function-backed exec reaches the existing runtime and can call nested tools.exec_command;
• live test against DeepSeek's official Responses endpoint using deepseek-v4-flash.

The live flow completed successfully:

DeepSeek Responses
-> function_call: exec
-> existing Code Mode runtime
-> tools.exec_command
-> pwd / ls -la in a read-only sandbox
-> function_call_output
-> correct final model response

One configuration gotcha found during testing:
excluded_tool_namespaces = ["functions"] also removes default-namespace nested tools such as exec_command, write_stdin, and apply_patch. Removing that exclusion restored them; this was a test configuration issue rather than a transport/runtime issue.

The POC is intentionally narrow and has not been pushed or opened as a PR. It validates the design and DeepSeek path, but vLLM, Ollama, OpenRouter, and Fireworks still need separate compatibility smoke tests.

The remaining design question is how maintainers want the capability expressed: an explicit provider configuration field, provider capability detection, or a conservative fallback for configured third-party Responses providers.

If this direction looks acceptable, I can clean up the POC into a reviewable PR.