v3 Autostart Disable cannot target a configured identifier

[tnware]

Problem

AutostartManager.EnableWithOptions accepts a stable AutostartOptions.Identifier, but Disable discovers registrations by the current executable instead of deleting that identifier. On Windows, a Run value left by an older installation path cannot be removed after the executable moves. The same discovery-based mismatch exists for Linux desktop files and macOS LaunchAgents.

A consumer can work around this by calling EnableWithOptions and then Disable, but that is not failure-atomic: if enable succeeds and disable fails, a previously disabled app becomes registered at login. Retrying the same sequence cannot reliably restore the disabled state.

Reproduction

1. Write a Windows Run value under a stable identifier, with the command pointing to an old executable path.
2. Start the application from a new path.
3. Call AutostartManager.Disable().
4. The stable value remains because windowsAutostart.find() matches only the current executable.

Proposed API

Add DisableWithOptions(AutostartOptions) (or an equivalent identifier-targeted operation) that validates and removes the exact registration identity used by EnableWithOptions. Keep existing Disable() behavior for compatibility.

Acceptance

• Windows removes the exact registry value even when its command points to a moved executable.
• Linux removes the exact .desktop filename.
• macOS removes the exact LaunchAgent label while preserving SMAppService cleanup.
• Empty options retain the existing default behavior.
• Invalid identifiers are rejected consistently.
• Native/platform tests cover idempotency and moved executable state.

[tnware]

hermes agent opened this automatically when it was moving a pre-existing auto start method to the wails v3 supported method. feel free to close if not relevant, i will leave it here for now and maybe follow up when my agent pulls the rest of this work out of backlog