Keep orchestrated remote children on the default computer-use setting

[warp-agent-staging]

Description

Orchestrated remote children were effectively hard-defaulting computer use to off. When a run_agents call omitted remote.computer_use_enabled, the client collapsed the unset flag to a plain false and then sent an explicit computer_use_enabled: false on each child's SpawnAgentRequest, which bypasses the server's normal default (ComputerUseEnabledOrDefault → on for the Oz harness). Skills had to hardcode computer_use_enabled: true just to get the standard cloud behaviour.

This carries the flag as a tri-state Option<bool> end to end:

• app/src/ai/agent/api/convert_from.rs — maps the wire bool onto Option<bool> instead of collapsing it into an explicit choice.
• crates/ai/src/agent/action/mod.rs — RunAgentsExecutionMode::Remote and StartAgentExecutionMode::Remote now carry computer_use_enabled: Option<bool>.
• app/src/ai/orchestration/remote_child.rs — new spawn_computer_use_enabled / effective_computer_use_enabled helpers. Unspecified leaves the field off the spawn request (it is skip_serializing_if = "Option::is_none"), so the server resolves its documented default: Oz → computer use on, third-party harnesses → off. An explicit choice still wins for Oz children.
• app/src/ai/orchestration/config_state.rs — the approved orchestration config no longer seeds a hard false; the plan carries no computer-use opinion, so plan-driven launches also start unspecified.

Local (non-remote) run_agents children are unaffected — computer use is remote-only on this tool. There is no user-facing surface for this flag (it is explicitly hidden from the orchestration editors), so this is headless orchestration plumbing with nothing to exercise in a UI; no computer-use/screenshot proof applies.

Known limitation / follow-up

The generated Rust proto for warp.multi_agent.v1.RunAgents.Remote.computer_use_enabled has no field presence — warp_multi_agent_api's codegen rewrites the editions source to syntax = "proto3", so an omitted flag and an LLM-set explicit false both decode as false on the client (Go keeps presence; Rust does not). The client therefore treats a wire false as "no opinion". Honouring an LLM-set explicit false end to end needs either field presence in the generated Rust proto (a warp-proto-apis change) or server-side resolution at run_agents emission; the plumbing here already carries Some(false) faithfully to the spawn request once that lands. A companion warp-server change (warpdotdev/warp-server#13672) hardens the server side of the same ticket.

Linked Issue

REMOTE-2444

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). — n/a, no user-visible surface.

Testing

Five regression tests were added; the two behavioural ones fail against the pre-fix mapping and pass after it (verified by temporarily restoring the old behaviour):

• ai::agent::api::convert_from::tests::run_agents_remote_without_computer_use_flag_stays_unspecified — a remote block whose computer_use_enabled arrives as the wire zero value stays None (fails pre-fix).
• ai::agent::api::convert_from::tests::run_agents_remote_with_computer_use_enabled_round_trips — explicit true still round-trips.
• ai::orchestration::remote_child::tests::unspecified_computer_use_is_omitted_from_the_child_spawn_request — the Oz child's spawn config omits the field.
• ai::orchestration::remote_child::tests::explicitly_disabled_computer_use_still_reaches_the_child_spawn_request and computer_use_is_dropped_for_third_party_harness_children.
• ai::orchestration::remote_child::tests::computer_use_resolution_mirrors_the_cloud_default plus ai::orchestration::config_state::tests::from_orchestration_config_leaves_computer_use_unspecified (fails pre-fix) and override_from_approved_config_preserves_explicit_computer_use.

Checks run locally:

• ./script/format and ./script/check_no_inline_test_modules — clean.

• cargo clippy -p warp -p ai -p warp_tui --all-targets --tests -- -D warnings — clean.

• cargo nextest run -p warp -p ai -p warp_tui — 7419 tests run, 7415 passed. The 4 failures are pre-existing sandbox-environment failures unrelated to this change: warp_tui session::tests::accepts_startup_without_resume and warp server::server_api::ai::tests::ambient_agent_headers_... fail because this cloud sandbox exports WARP_API_KEY / an ambient-agent workload token (re-running the first with env -u WARP_API_KEY passes), and terminal::input::tests::test_histignorespace_support_in_zsh / terminal::input::decorations::tests::test_decorations_with_multibyte_chars depend on a local shell/terminal environment. CI is the full-suite gate.

• I have manually tested my changes locally with ./script/run — not applicable: this is headless orchestration plumbing behind a cloud run_agents dispatch with no rendered surface, verified with the tests above.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Originating thread: https://warpdev.slack.com/archives/C0BDQDW8V5E/p1785519725716929

Conversation: https://staging.warp.dev/conversation/ad9c4a6a-27a1-4e1c-a8cc-ff7cc422816c
Run: https://oz.staging.warp.dev/runs/019fb952-9159-7961-ba04-dce0d927e266

This PR was generated with Oz.