Feat/add option to change virtual drive path

[egalvis27]

What is Changed / Added

Virtual Drive Root Path Selection

This PR introduces the ability for users to choose where the Internxt virtual drive is mounted on their system.

How it works

The user selects a base directory (e.g. ~/Downloads). The app always creates a fixed subfolder called Internxt Drive inside it, so the final mount point is always <base>/Internxt Drive/. This separation ensures the FUSE filesystem is isolated and never conflicts with the user's own files in the chosen folder.

The selected base path is persisted in the config store under virtualDriveRoot. The legacy syncRoot key is kept in sync for backwards compatibility with older code paths that still read it.

Remount lifecycle

Changing the root path triggers a full remount cycle orchestrated by remountVirtualDriveOnRootChange:

1. Stop — The running FUSE daemon receives SIGTERM. The Go process calls server.Unmount() to detach the filesystem from the kernel. If that fails (e.g. the file manager has the folder open), the daemon still exits.

2. Stale mount cleanup — Before deleting the old directory, fusermount3 -uz <oldPath> is issued as a lazy unmount. This forces the kernel to release the mount entry even if the daemon exited without cleanly unmounting, preventing ENOTCONN errors on subsequent filesystem operations.

3. Old directory removal — The previous Internxt Drive folder is deleted. Several safety guards prevent accidental deletion: the path must be non-empty, must not resolve to /, and must not resolve to the user's home directory.

4. Start — A new FUSE daemon is spawned with the updated INTERNXT_MOUNT environment variable pointing to the new path. The folder is created automatically if it does not exist.

Boot ID correlation

Each daemon spawn generates a random bootId (UUID). It is passed to the Go process via INTERNXT_BOOT_ID and echoed back in the POST /daemon/ready HTTP payload. The Node.js side validates that the received boot ID matches the active one before resolving the startup promise. This prevents a stale ready signal from a slow-exiting previous daemon from being mistaken for the new daemon being ready.

Concurrency guards

Both stopVirtualDriveOnce and remountVirtualDriveOnRootChange deduplicate concurrent calls via an in-flight promise. If a remount is already in progress when a second call arrives (e.g. the user clicks "Change" twice), the second caller awaits the same promise rather than starting a parallel remount. The in-flight reference is cleared in a finally block so subsequent calls can proceed normally after completion or failure.

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud