Extract tool spec helpers into codex-tools (#16471)

## Why

Follow-up to #16379.

`codex-rs/core/src/tools/spec.rs` and the corresponding handlers still
owned several pure tool-definition helpers even though they do not need
`codex-core` runtime state. Keeping that spec-only logic in `codex-core`
keeps the crate boundary blurry and works against the guidance in
`AGENTS.md` to keep shared tooling out of `codex-core` when possible.

This change takes another step toward a dedicated `codex-tools` crate by
moving more metadata and schema-building code behind the `codex-tools`
API while leaving the actual tool execution paths in `codex-core`.

## What Changed

- Added `codex-rs/tools/src/apply_patch_tool.rs` to own
`ApplyPatchToolArgs`, the freeform/json `apply_patch` tool specs, and
the moved `tool_apply_patch.lark` grammar.
- Updated `codex-rs/tools/BUILD.bazel` so Bazel exposes the moved
grammar file to `codex-tools`.
- Moved the `request_user_input` availability and description helpers
into `codex-rs/tools/src/request_user_input_tool.rs`, with the related
unit tests moved alongside that business logic.
- Moved `request_permissions_tool_description()` into
`codex-rs/tools/src/local_tool.rs`.
- Rewired `codex-rs/core/src/tools/spec.rs`,
`codex-rs/core/src/tools/handlers/apply_patch.rs`, and
`codex-rs/core/src/tools/handlers/request_user_input.rs` to consume the
new `codex-tools` exports instead of local helper code.
- Removed the now-redundant helper implementations and tests from
`codex-core`, plus a couple of stale `client_common` re-exports that
became unused after the move.

## Testing

- `cargo test -p codex-tools`
- `cargo test -p codex-core tools::spec::tests`
- `cargo test -p codex-core tools::handlers::apply_patch::tests`

codex-rs/tools/src/request_user_input_tool.rs

@@ -1,6 +1,8 @@
 use crate::JsonSchema;
 use crate::ResponsesApiTool;
 use crate::ToolSpec;
+use codex_protocol::config_types::ModeKind;
+use codex_protocol::config_types::TUI_VISIBLE_COLLABORATION_MODES;
 use std::collections::BTreeMap;
 
 pub fn create_request_user_input_tool(description: String) -> ToolSpec {
@@ -89,6 +91,47 @@ pub fn create_request_user_input_tool(description: String) -> ToolSpec {
     })
 }
 
+pub fn request_user_input_unavailable_message(
+    mode: ModeKind,
+    default_mode_request_user_input: bool,
+) -> Option<String> {
+    if request_user_input_is_available(mode, default_mode_request_user_input) {
+        None
+    } else {
+        let mode_name = mode.display_name();
+        Some(format!(
+            "request_user_input is unavailable in {mode_name} mode"
+        ))
+    }
+}
+
+pub fn request_user_input_tool_description(default_mode_request_user_input: bool) -> String {
+    let allowed_modes = format_allowed_modes(default_mode_request_user_input);
+    format!(
+        "Request user input for one to three short questions and wait for the response. This tool is only available in {allowed_modes}."
+    )
+}
+
+fn request_user_input_is_available(mode: ModeKind, default_mode_request_user_input: bool) -> bool {
+    mode.allows_request_user_input()
+        || (default_mode_request_user_input && mode == ModeKind::Default)
+}
+
+fn format_allowed_modes(default_mode_request_user_input: bool) -> String {
+    let mode_names: Vec<&str> = TUI_VISIBLE_COLLABORATION_MODES
+        .into_iter()
+        .filter(|mode| request_user_input_is_available(*mode, default_mode_request_user_input))
+        .map(ModeKind::display_name)
+        .collect();
+
+    match mode_names.as_slice() {
+        [] => "no modes".to_string(),
+        [mode] => format!("{mode} mode"),
+        [first, second] => format!("{first} or {second} mode"),
+        [..] => format!("modes: {}", mode_names.join(",")),
+    }
+}
+
 #[cfg(test)]
 #[path = "request_user_input_tool_tests.rs"]
 mod tests;