Correction: why fork()+$save from VPI fails under VCS -ucli2Proc (the child waits on the UCLI process)

Follow-up to my note on non-blocking VCS saves by fork() from VPI plus $save in the child. I wrote that under -ucli the parent gets SIGTERM. That was my own bug: after fork the child returned into my library's serve loop, read its closed control pipe, and my 'controller lost' path killed the whole process group. Rules for the child: never re-enter your command loop, never read or write the control pipes, and never run group cleanup. Return straight to the simulator so it reaches $save at the next step, then _exit.

Measured after the fix (W-2024.09): - -ucli -ucli2Proc: the parent is fine, but the child's $save writes ucliCore::ucliPreSsave <file>.FILES to its stdout (a request to the UCLI process) and waits in poll for a reply that never comes. No image is written. - Single-process -ucli: the image is written, but simv -r of it doesn't run to its end. - Plain simv (no -ucli): idle and mid-run saves restore exactly.

Also: - $save creates a missing parent folder. To test a failing save, use a path whose parent is a regular file. - Make the child's exit status mean something: waitpid(-1) for its children (the compressor), stat() the image, scan its log for [VCS_SAVE_RESTORE] errors. - Give each child a deadline, and kill its process tree when it passes.