feat(scheduler): allow a custom command for scheduled tasks

[xchacha20-poly1305]

Closes #498

Problem

All three scheduler backends resolved the program the OS should wake up from ProcessHandle.current().info().command(). Apps that bootstrap through a custom launcher therefore had the OS start the JVM/native binary rather than the launcher, and there was no way to override it.

Solution

SchedulerConfig (new, modelled on the existing AutoLaunchConfig):

SchedulerConfig.executablePath = "/opt/myapp/myapp-launcher"
SchedulerConfig.executableArguments = listOf("--background")

DesktopTaskScheduler.enqueue(TaskRequest.periodic(TaskId("sync"), 1.hours))

The scheduled invocation becomes <executablePath> <executableArguments…> --nucleus-scheduler-run <taskId>. Leaving both unset keeps today's behavior exactly, so this is additive — no API break.

Implementation notes

• New internal object SchedulerExecutable resolves the command for all three backends and centralizes the scheduler flag on DesktopBootReceiver.SCHEDULER_ARG, replacing the three duplicated executablePath getters and two copies of the constant.
• Threaded through LinuxSystemdScheduler, MacOSLaunchdScheduler (native + shell plist, and both retry paths) and WindowsTaskScheduler (wscript wrapper + retry fallback).
• TaskWrapperScript gained an execArgs parameter, and content generation is split from file writing (buildLinuxScript / buildWindowsScript) so the generated scripts are unit-testable.
• Escaping fixes that fell out of passing user-supplied arguments through: Linux script values are single-quote escaped instead of naively wrapped in "…", Windows arguments containing spaces are quoted, and macOS plist <string> values are XML-escaped (they were interpolated raw before).
• The wrapper scripts still test the configured executable for existence and self-destruct when it is gone, so a custom launcher must be an absolute path — documented in the SchedulerConfig KDoc.

Testing

• :scheduler:test :scheduler:apiCheck :scheduler:detekt :scheduler:ktlintCheck :scheduler-testing:test pass; scheduler/api/scheduler.api re-dumped.
• New SchedulerExecutableTest (resolution order, blank override ignored, argument ordering) and TaskWrapperScriptTest (Linux/Windows wrapper content, escaping, self-destruct branch).
• Manually verified on Linux: generated a real wrapper script against a dummy launcher, which ran as launcher --background "--log dir" --nucleus-scheduler-run sync with the space-containing argument preserved as one argument; deleting the launcher made the script correctly unregister and delete itself.
• macOS and Windows are covered by unit tests only — I could not exercise launchd / Task Scheduler locally.

[kdroidFilter]

can you fix the ci ?

[xchacha20-poly1305]

can you fix the ci ?

The test all passed on my machine. Can you re-run it? My change isn't relevant to decorated-window-tao.