fix(v1): allow concurrent borrowed runtime environments

[parkerpettit]

Summary

• give each borrowed rollout its own environment-scoped runtime view
• allow multiple agents to share one sandbox concurrently
• preserve sandbox-level network policy validation
• preserve owner lifecycle checks against the physical runtime

Why

#2362 added a rollout-wide lock because borrowed rollouts were applying their process environment directly to the shared runtime. Without serialization, concurrent agents could overwrite each other’s environment variables.

The lock prevented that race, but it also serialized the entire lifetime of every borrowed rollout. This can deadlock nested-agent workflows:

1. Agent 1 opens and retains the sandbox.
2. Agent 1 acquires the borrow lock.
3. Agent 2 is launched in the same sandbox.
4. Agent 1 needs Agent 2’s response to finish.
5. Agent 2 cannot start until Agent 1 releases the lock.
6. Neither agent can make progress.

This PR removes the need for that lock by using Runtime.with_env(). Each rollout gets its own process-environment view while continuing to share the same underlying sandbox handles. Concurrent rollouts therefore cannot overwrite each other’s environment, which preserves the isolation the lock was added to provide without serializing agents.

Network policy remains sandbox-scoped. The existing borrowed-placement validation rejects any agent or task whose required policy is incompatible with the sandbox. All valid borrowers therefore share the same network policy and can run concurrently.

Owner lifecycle checks continue to operate on the physical runtime, so the sandbox cannot be closed or replaced while borrowed agents are using it.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes the production borrowed-runtime lifecycle from serialized use to concurrent use by introducing shallow views that share provider state while isolating environments. This cross-runtime concurrency and cleanup change has broader operational impact than a routine isolated bug fix and merits human review.

Not approved because:

• Monthly spending limit reached (workspace setting). Approvability relies on correctness review in order to determine eligibility

^{Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more.}