refactor: extract executable tool contracts into codex-tool-api (#22138)

## Why
The tool-extraction work needs one shared executable-tool seam that
hosts and tool owners can depend on without reaching into `codex-core`.
Landing that seam first makes the later tool-family ports incremental
and keeps the reusable contract separate from any one migration.

## What changed
- add a new `codex-tool-api` crate and workspace wiring
- move the common executable-tool contracts into that crate:
`ToolBundle`, `ToolDefinition`, `ToolExecutor`, `ToolCall`, `ToolInput`,
`ToolOutput`, `JsonToolOutput`, and `ToolError`
- keep host state generic through `ToolBundle<C>` / `ToolCall<C>` so
later integrations can provide their own runtime context without baking
core types into the API
- carry the host signals the runtime will need later, including
parallel-call support and mutability probing
- leave existing tool families in place for now; this PR only
establishes the reusable API surface
- add the Bazel target and lockfile updates for the new crate

## Testing
- `cargo test -p codex-tool-api`

codex-rs/tool-api/src/bundle.rs

@@ -0,0 +1,79 @@
+use std::future::Future;
+use std::pin::Pin;
+use std::sync::Arc;
+
+use codex_tools::ToolName;
+use codex_tools::ToolSpec;
+
+use crate::ToolCall;
+use crate::ToolError;
+use crate::ToolOutput;
+
+/// Future returned by one executable-tool invocation.
+pub type ToolFuture<'a> =
+    Pin<Box<dyn Future<Output = Result<Box<dyn ToolOutput>, ToolError>> + Send + 'a>>;
+
+/// Future returned by one mutability probe.
+pub type BoolFuture<'a> = Pin<Box<dyn Future<Output = bool> + Send + 'a>>;
+
+/// Model-visible definition plus executable implementation for one tool.
+#[derive(Clone)]
+pub struct ToolBundle<C> {
+    definition: ToolDefinition,
+    executor: Arc<dyn ToolExecutor<C>>,
+}
+
+impl<C> ToolBundle<C> {
+    /// Creates one executable tool bundle.
+    pub fn new(name: ToolName, spec: ToolSpec, executor: Arc<dyn ToolExecutor<C>>) -> Self {
+        Self {
+            definition: ToolDefinition {
+                name,
+                spec,
+                supports_parallel_tool_calls: false,
+            },
+            executor,
+        }
+    }
+
+    /// Marks this tool as safe for the host to run in parallel with peers.
+    #[must_use]
+    pub fn allow_parallel_calls(mut self) -> Self {
+        self.definition.supports_parallel_tool_calls = true;
+        self
+    }
+
+    /// Returns the model-visible tool definition.
+    pub fn definition(&self) -> &ToolDefinition {
+        &self.definition
+    }
+
+    /// Returns the executable implementation.
+    pub fn executor(&self) -> Arc<dyn ToolExecutor<C>> {
+        Arc::clone(&self.executor)
+    }
+}
+
+/// Model-visible metadata owned by an executable tool bundle.
+#[derive(Clone)]
+pub struct ToolDefinition {
+    pub name: ToolName,
+    pub spec: ToolSpec,
+    pub supports_parallel_tool_calls: bool,
+}
+
+/// Executable behavior for one contributed tool.
+///
+/// Implementations should keep host-specific needs inside `C`; tool owners that
+/// do not require host state can implement the trait for any `C`.
+pub trait ToolExecutor<C>: Send + Sync {
+    fn execute<'a>(&'a self, call: ToolCall<C>) -> ToolFuture<'a>;
+
+    /// Returns whether the call may mutate user state.
+    ///
+    /// Hosts can use this conservative signal for serialization or approval
+    /// policy. Context-free read tools should keep the default.
+    fn is_mutating<'a>(&'a self, _call: &'a ToolCall<C>) -> BoolFuture<'a> {
+        Box::pin(async { false })
+    }
+}