fix(sandbox): keep UnixLocal filesystem and tar work off the event loop - #4678

This pull request fixes persist_workspace and hydrate_workspace holding the asyncio event loop while they archive or extract the entire workspace tree.

The bug

Both methods are async def but do their work with synchronous tarfile and pathlib calls, and both sit on the snapshot lifecycle — persist_snapshot() awaits persist_workspace(), and restore_snapshot_into_workspace_on_resume() awaits hydrate_workspace():

async def persist_workspace(self) -> io.IOBase:
    ...
    with tarfile.open(fileobj=buf, mode="w") as tar:
        tar.add(root, arcname=".", filter=...)   # walks and reads the whole tree

A workspace holding a node_modules, a build directory, or a model checkpoint takes seconds to minutes to archive, and for that whole window nothing else on the loop runs: concurrent agent runs, streamed responses, MCP sessions, and tracing exports all freeze.

The change

The blocking bodies move into two module-level helpers, _archive_workspace and _extract_workspace_archive, run on a worker thread. Session state is read on the loop — persist_workspace reads manifest.root and _persist_workspace_skip_relpaths() itself — and only plain values cross into the thread.

Cancellation ownership. asyncio.to_thread cannot interrupt the thread it starts, so awaiting it plainly would report the operation as stopped while the worker is still walking or writing the workspace. Callers act on that return immediately: the snapshot lifecycle closes the archive stream in a finally as soon as the await returns, and resume clears the workspace root. Either would land on a live worker.

_run_workspace_io therefore records the cancellation, lets the worker settle, and only then propagates it. Repeated cancellation is absorbed the same way, and a worker failure that arrives after cancellation is consumed rather than surfacing instead of the cancellation. This follows memory.sqlite_session._await_mutation, which owns cancellation for session writes; if you would rather hoist that helper into a shared util than have a second copy, say the word.

Scope

Per review, this is limited to the two operations with a demonstrated defect. The bounded mkdir, exists, and resolve calls in _prepare_backend_workspace, _resolved_exec_context, _exec_internal, pty_exec_start, and _write_stream_with_exec are unchanged, so ruff --select ASYNC still reports ASYNC240 at those five sites. Leaving them alone also keeps this change off the exec confinement path.

Behavior

• Error types, messages, and context payloads are unchanged. The helpers keep the same guards and raise the same WorkspaceArchiveReadError and WorkspaceArchiveWriteError, including the workspace_root_not_found reason.
• No public API change, and no change to any private signature outside these two methods.

Tests

tests/sandbox/test_unix_local.py covers both properties the review asked for.

Event-loop responsiveness — two tests hold the archive/extract helper open until a coroutine scheduled alongside it has run, so doing that work on the loop deadlocks instead of passing.

Cancellation — three tests hold the worker open, cancel the task, and assert it has neither completed nor let the worker settle, then release the worker and assert CancelledError surfaces only afterwards. One covers repeated cancellation. All three fail against a plain await asyncio.to_thread(...), on assert not task.done(). A fourth pins that a worker failure arriving after cancellation still reports as cancelled.

Two behavior guards round it out: a persist-then-hydrate round trip, and a missing workspace root still raising WorkspaceArchiveReadError.

Because this module refuses to import on Windows by design, verification ran on Linux: tests/sandbox is 1435 passed, 22 skipped, and mypy is clean on the module.

Resolves #4675.