Resolves#36024 and #34501.
Main change is about stop using the first user in the `users` command
output [*] and instead use `loginctl` commands to pick the correct
current active GUI user.
[*] `users` was returning empty on some new distributions, and in
multi-sessions we were always picking the first one (even if it wasn't
active).
- [X] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
## Testing
- [x] QA'd all new/changed functionality manually
## fleetd/orbit/Fleet Desktop
- [x] Verified compatibility with the latest released version of Fleet
(see [Must
rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md))
- [x] If the change applies to only one platform, confirmed that
`runtime.GOOS` is used as needed to isolate changes
- [x] Verified that fleetd runs on macOS, Linux and Windows
- [x] Verified auto-update works from the released version of component
to the new version (see [tools/tuf/test](../tools/tuf/test/README.md))
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Bug Fixes**
* Fixed Fleet Desktop startup to correctly detect and use the active GUI
session on Linux systems.
* Improved GUI user detection for dialog prompts, ensuring system
dialogs run in the proper user context.
* **Improvements**
* Enhanced error reporting and logging clarity for GUI session detection
failures.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
For #25924
This PR attempts to fix the issue where the Fleet desktop icon sometimes
fails to appear on MacOS hosts until the hosts are rebooted. Anecdotal
evidence points to this being an issue when system setup is happening,
leading to the theory that Orbit is attempting to launch the app as
`_mbsetupuser` rather than the real logged-in user. The fix here is to
use a different command to get the name of the logged-in user (ignoring
`_mbsetupuser` if it appears), and to launch the desktop app as that
user using `sudo`.
I have tested this on MacOS and Ubuntu hosts, and verified that the
desktop app launches as expected on both.
We don't have a solid reproduction scenario for the issue, but we do
have [some ways to look for relevant
errors](https://github.com/fleetdm/fleet/issues/19172#issuecomment-2627812786),
so we can try this out and see if those errors cease.
this accomplishes two things:
1. We're not waiting on Nudge to exit anymore, preventing issues like
https://github.com/fleetdm/fleet/issues/10044
2. Nudge is launched as a local user instead of root, which is the
recommended way to do it.
* Orbit: Add Fleet Desktop support to Windows
* Rename workflow, fix linux build
* Do not compile systray on linux
* nolint on unused
* Fix lint properly
* nolint both checkers
* Fix monitor logic in desktopRunner
* Fix interrupt and execute order
