Identify and remove the global sync(2) call that blocked the Studio UI thread on a stalled network mount

The first launch of Studio after a build froze for over 20 seconds on macOS while opening a project, and the process had to be force-killed. A macOS hang report (stackshot) shows the main thread blocked for the entire sampling window inside the global sync(2) filesystem syscall, which walks every mounted filesystem. The machine had an SMB NAS share mounted whose connection was busy at that moment; the sync therefore blocked in smbfs_sync behind the stalled network mount. Subsequent launches were unaffected.

Studio's own source does not call sync(2) (verified), and the .NET runtime never issues a global sync. The caller is a frame inside the Studio process that the crash dump cannot symbolicate (managed JIT frames carry no symbols in stackshots). This issue tracks the investigation: identify the caller from a live capture if the hang recurs, and remove or replace any global-sync-on-the-UI-thread usage found.