refactor js_repl to reuse managed child process infra

[fjord-oai]

Summary

This change pushes the js_repl refactor further toward the natural unified_exec reuse boundary without trying to collapse two different execution models into one abstraction.

The result is:

• js_repl now reuses shared sandbox selection / transform
• js_repl now reuses shared managed child process lifecycle
• unified_exec now has a small internal cleanup so merged-output and split-output exec-env spawns share one private implementation

This keeps js_repl’s kernel protocol, per-exec_id polling, and async tool-call handling intact, while removing low-level process/sandbox duplication.

What Changed

• Extracted shared sandbox initialization into SandboxAttempt::initial_for_turn(...)
  • centralizes initial sandbox selection
  • centralizes managed-network requirement detection
  • centralizes platform-specific sandbox settings like use_linux_sandbox_bwrap
• Updated the tool orchestrator to use that shared sandbox helper
• Refactored js_repl kernel startup
  • builds its initial ExecRequest through the shared sandbox path
  • starts the kernel through unified_exec_manager
  • reuses UnifiedExecProcess lifecycle handling
  • still consumes split stdout/stderr because stdout carries the kernel protocol and stderr is retained for diagnostics
• Added ManagedSplitProcess
  • wraps a managed child process plus split stdout/stderr receivers
  • gives js_repl access to the shared managed child layer without forcing it into the merged-output API
• Internally unified unified_exec exec-env spawn helpers
  • open_session_with_exec_env(...)
  • open_split_pipe_session_with_exec_env(...)
  • now share one private spawn helper and keep thin public wrappers

Rationale

The original js_repl implementation duplicated logic that already exists in or adjacent to unified_exec:

• sandbox selection / transform
• child process startup
• pid / exit tracking
• cancellation / termination
• buffered output lifecycle

Those are the parts that are expensive to get right and worth centralizing.

At the same time, js_repl is not just “another unified_exec session”:

• it runs a persistent kernel
• it multiplexes many logical exec_ids over one process
• it polls per-exec structured state, not just process output
• it supports async kernel->host RunTool requests while an exec is running

So the goal here is not “make js_repl a thin wrapper over exec_command / write_stdin”.
The goal is “reuse the shared substrate where the abstractions actually match”.

Why Not Reuse All of unified_exec?

We can reuse the managed-child substrate, but not the whole unified_exec process model.

unified_exec is process-centric:

• one process/session id
• merged process output
• polling via destructive drain of process output
• completion mostly tied to process exit / persisted process session state

js_repl is exec-centric inside a persistent kernel:

• many logical exec_ids within one kernel
• structured per-exec state (logs, output, content_items, done, error)
• completion signaled by kernel protocol messages like ExecResult
• async RunTool round-trips while an exec is still active

That means:

• sandbox reuse: good fit
• child lifecycle reuse: good fit
• low-level wait/notify ideas: maybe reusable
• direct reuse of write_stdin polling / generic unified-exec completion semantics: not a good fit

Trying to force js_repl through that API would likely produce an abstraction that is technically shared but harder to reason about on both sides.

git stack

• ⏳ 1 Add feature-gated js_repl polling flow #10673
• ⏳ 2 Add multimodal outputs to js_repl polling #13081
• 👉 3 refactor js_repl to reuse managed child process infra #13266