Fix Windows auto-launch registration for restart/login

[piaoguodeafei]

Tari Universe Windows Auto-Launch PR Draft

Title

Fix Windows auto-launch registration for restart/login

Summary

• Use Windows Task Scheduler as the single Windows auto-launch path instead of mixing it with the auto-launch registry entry.
• Remove any legacy registry auto-launch entry whenever the setting is applied, preventing duplicate or stale startup registrations.
• Delete the scheduled task when the setting is turned off instead of re-registering it with a disabled trigger.
• Register the startup task without requesting the highest run level, so the app can relaunch after user login without depending on elevated startup behavior.
• Add small Windows-only unit tests for the stable scheduled task name and schtasks arguments.
• Fix a Windows compile break in data_location.rs by defining DRIVE_REMOTE locally; the current windows-sys dependency exposes GetDriveTypeW from Storage::FileSystem, but DRIVE_REMOTE is not exported from that module.

Verification

• git diff --check passed locally.
• cargo fmt -- --check passed locally.
• Built process-wrapper sidecar with cargo build --manifest-path process-wrapper/Cargo.toml.
• cargo test auto_launcher::tests:: passed locally on Windows: 3 passed, 0 failed, 189 filtered out.
• Note: running the test binary without __COMPAT_LAYER=RunAsInvoker fails with Windows UAC os error 740 because the app manifest requests administrator privileges. The compatibility layer was used only to run the unit tests without elevation.

Local Commit

• 389cb72 fix: use task scheduler for Windows auto-launch

Issue

Closes #1588

[gemini-code-assist]

Code Review

This pull request refactors the auto-launcher implementation on Windows to utilize the Task Scheduler via schtasks, replacing legacy registry-based entries. Key changes include the addition of task management helpers, unit tests for Windows-specific task arguments, and a modification to the task's execution run level. Review feedback points out that lowering the run level to LUA may cause launch failures if the application manifest requires administrative privileges. Additionally, it is recommended to suppress stderr output during task existence checks to avoid unnecessary log noise.

[gemini-code-assist]

Changing the run_level to RunLevel::LUA (Least Privileged User Account) might prevent the application from starting if its manifest requires administrator privileges (requireAdministrator). The PR description mentions that the app manifest requests administrator privileges and that running without a compatibility layer fails with error 740. In such cases, Task Scheduler will fail to launch the process unless the task itself is run with highest privileges. If the intention is to have the app auto-launch successfully while requiring admin, RunLevel::Highest is usually necessary to bypass the UAC prompt at logon.

[gemini-code-assist]

The schtasks /Query command prints an error message to stderr if the task does not exist. Since this function is called to check for existence, these error messages might clutter the console or logs when the app is run from a terminal. It is better to redirect the output to Stdio::null() to keep the output clean.

Suggested change

	fn startup_task_exists(&self) -> Result<bool, Box<dyn std::error::Error>> {
	let status = Command::new("schtasks")
	.args(windows_query_task_args())
	.status()?;
	Ok(status.success())
	}
	fn startup_task_exists(&self) -> Result<bool, Box<dyn std::error::Error>> {
	let status = Command::new("schtasks")
	.args(windows_query_task_args())
	.stdout(std::process::Stdio::null())
	.stderr(std::process::Stdio::null())
	.status()?;
	Ok(status.success())
	}