Run VMs on other Macs: one pool of Macs for vmpal commands and vmpal run

Description

Let vmpal drive VMs on other Macs running VMPal on the same network (paired once, e.g. in
Settings, like AI Agents access), so that several Macs work as one pool:

1. A host for any command: vmpal --on <Mac> clone|start|exec|cp|ui|delete|…. exec
   streams its output and passes on its exit status. cp copies between this Mac's files and a
   VM on the other Mac directly (vmpal cp ./build/. <Mac>:<VM>:path, and back).
2. A pool for vmpal run: a job in a throwaway clone of a shut-down VM can run on any paired
   Mac that has the VM and a free slot, and its output files come back to this Mac. A way to run
   several jobs at once over the pool (e.g. vmpal run … --parallel, or a list of jobs) would
   replace a project's own scheduler.
3. The same VM on several Macs: a VM can be copied to a paired Mac and kept in step. macOS and
   VMPal Tools updates are done once; settings and the account password are carried along.
   vmpal info / vmpal list show where each copy is and whether the copies differ.
4. Clean up on its own: clones a job made on another Mac are deleted when the job ends. If
   this Mac loses the connection, the other Mac deletes them itself after a timeout.

Any of these alone helps: (1) removes the SSH and rsync glue, (2) the scheduling, (3) the drift
between copies.

Why this feature/change is important?

macOS runs at most two macOS VMs at once per Mac, so a test suite split over clones is limited to
two parallel jobs per Mac. Many developers have a second Mac with VMPal on the same network (a
laptop beside a desktop, an older Mac) that sits idle while the tests run.

Using it today means wrapping every vmpal call in SSH and rebuilding what VMPal already does
locally:

• running vmpal on the other Mac over SSH, with streamed output and exit statuses, and quoting
  every argument;
• copying the build there (rsync) before vmpal cp can put it into a clone, and copying the
  results (logs, screenshots, crash reports) back the same way;
• deleting that Mac's clones when the SSH connection drops mid-run;
• moving each golden VM over in the first place (vmpal compress / import, tens of GB each),
  and keeping the copies alike afterwards: macOS updates, VMPal Tools versions, settings, and the
  account passwords in each Mac's keychain;
• scheduling: two jobs per Mac, the next job on whichever Mac has a free slot, and everything
  locally when the other Mac is asleep or away.

Every project that wants this writes the same glue, and making its failures clean over SSH is hard:
dropped connections, clones left behind, a Mac that fell asleep. Hooks don't cover it either: a
hook runs a script on one Mac, but returning the job's output and files to the Mac that started it,
and spreading jobs over Macs, are left to the caller.

For example, our e2e suite has about 100 GUI tests in five runs: macOS 15, 26 and 27, and an Intel
build under Rosetta on 15 and 26. With a second Mac, a full run would take about 12 minutes
instead of 22. The tests drive the VMs' UI (vmpal ui, and input inside the VM through VMPal
Tools), so a VM on another Mac must behave exactly like a local one. Both Macs are Apple silicon,
with the same VMPal version. Happy to test a preview.