cow: a large copy-up stalls the supervisor for its whole duration #242

handle_cow_open and handle_cow_write run the copy-up on a blocking thread but await it on the supervisor loop, which handles one notification at a time. Until the copy ends, no other notification is received, so every notified syscall of every other sandboxed process waits.

Measured on main: opening a 400 MB file with O_WRONLY in a --workdir sandbox takes about 0.6 s, and an open("/etc/hostname") issued by another process during that time waits for it. Small files are not a problem (about 1.5 ms per MiB here).

A side effect: a syscall waiting that long is exposed to the signal race in #235 for the whole time. With SIGALRM (handler without SA_RESTART) delivered during the wait, the other process's open failed with EINTR 3 of 3 times.

Moving the copy off the loop is not a small change:

• execute_copy writes the final upper path with O_CREAT | O_TRUNC, so a half-written file exists during the copy. Nothing sees it today only because no other handler runs meanwhile.
• A second writer must wait for the first copy rather than copy again, or the first writer's data is lost at commit.
• The generic Defer path fails the syscall with EIO after 30 s and with EAGAIN beyond 64 in flight, neither of which fits a file copy.
• A task left received and unanswered cannot be stopped by the execve argv freeze (policy_fn), and learn combines a policy_fn with a COW workdir.

One possible shape: a per-branch gate held only during large copies, with the other COW handlers waiting behind it off the loop, so COW stays serialized as it is today and everything else proceeds. Low priority.