Fix AlwaysOnTop sound playing when pin/unpin fails

[Copilot]

Summary of the Pull Request

ProcessCommand played the pin/unpin sound unconditionally, regardless of whether SetWindowPos succeeded. This caused spurious audio feedback when targeting desktop, taskbar, task view, start menu, or elevated windows from a non-elevated process.

Gate sound playback on actual state change:

bool stateChanged = false;
// ...
if (UnpinTopmostWindow(window)) { stateChanged = true; /* ... */ }
// ...
if (PinTopmostWindow(window))   { stateChanged = true; /* ... */ }
// ...
if (stateChanged && AlwaysOnTopSettings::settings()->enableSound)
    m_sound.Play(soundType);

PR Checklist

• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

PinTopmostWindow and UnpinTopmostWindow already return bool indicating success, and the existing code already branches on those return values for bookkeeping and telemetry — but the sound playback at the end of ProcessCommand ignored the result. Added a stateChanged flag set only inside the success branches, then checked before calling m_sound.Play().

Validation Steps Performed

• Verified that the soundType / stateChanged logic covers all four paths: pin success, pin failure, unpin success, unpin failure.
• Code review passed with no comments.

[niels9001]

@vanzue Can you verify if the changes make sense?

[vanzue]

The code looks straight forward, and I'm just hesitating about the behavior, imagine I'm trying to hit shortcut, nothing changed, and nothing happen(sound), I will then wonder whether if I'm hitting the wrong hotkey for it, so currently user know something is happening, but he pin/unpin failed, I'm not sure which one is prefered

[niels9001]

The code looks straight forward, and I'm just hesitating about the behavior, imagine I'm trying to hit shortcut, nothing changed, and nothing happen(sound), I will then wonder whether if I'm hitting the wrong hotkey for it, so currently user know something is happening, but he pin/unpin failed, I'm not sure which one is prefered

1. Do we know why this fails sometimes?
2. Users might turn off the sounds (I do), I still don't get any feedback if it doesn't work. So yeah, this 'bug' kinda addresses it but not always.
3. I think we should fix this bug, and then figure out what a good way is to let users know it didn't work.

Thoughts?

[vanzue]

OK, agree, some window can't be pinned, I think this pr is safe and helps, although some distance from absolute fix.
For 1, I can't get a full picture yet, but I think I'm good with this pr