fix(core): eliminate TOCTOU in MachineManager::create by holding write lock

[AprilNEA]

Summary

• Take write lock at the start of create() instead of read-then-write
• Existence check and insert are now atomic with respect to other writers
• Prevents concurrent creates from duplicating VMs and orphaning filesystem directories

Test plan

• Concurrent arcbox machine create from CLI + desktop doesn't duplicate

Closes ABX-230

[linear]

ABX-230 MachineManager::create() TOCTOU — concurrent creates can duplicate VMs

[Copilot]

Pull request overview

This PR addresses a race in MachineManager::create() where concurrent creates using the same machine name could both pass an existence check and then overwrite each other on insert, potentially leaving orphaned VM resources/directories.

Changes:

• Acquire the machines write lock at the start of create() to make the existence check + insert atomic.
• Reuse the same write guard for the final insert() to avoid the read-then-write TOCTOU window.

[Copilot]

create() now holds a std::sync::RwLock write guard while doing filesystem I/O (create_dir_all), VM creation, and persistence writes. That can block all readers/writers of machines (e.g., list/get/start) for the entire duration of a potentially slow operation, impacting daemon responsiveness. Consider reserving the name under the lock (e.g., track an in-progress set or insert a temporary "creating" entry) and then releasing the lock while performing I/O, or using an atomic filesystem reservation (e.g., create_dir/lockfile with create_new) to avoid the TOCTOU without a long-lived global write lock.

[Copilot]

This change is specifically about preventing concurrent creates from duplicating/overwriting machines, but there’s no test asserting the new behavior. Since this file already has async tests, please add a concurrency test that runs two create() calls with the same name in parallel and asserts exactly one succeeds (the other returns already-exists) and that only one machine is registered/persisted.