Fix uwsm-app issue & restore hyprland relaunch ability for VMs

[jondkinney]

For ARM based VMs in Parallels and VMware we need to be able to issue hyprctl dispatch exit to relaunch Hyprland fully. This is because Hyprland only detects monitor resolutions when it first launches. It caches them, and only allows switching to the "known" resolutions in its cache.

This is problematic for VMs where you can resize the window (or go full screen) which creates a new highly custom "resolution" that Hyprland can't handle dynamically. Parallels Tools and VMware Tools are only capable of auto-detecting and adjusting resolutions for X11 window environments, not Wayland composers, currently.

Ideally Vaxry could update Hyprland to detect dynamic resolution changes and issue the hyprctl rescan-outputs command that re-runs DRM_IOCTL_MODE_GETCONNECTOR so that we can dynamically re-render the desktop at the new available resolution without skewing/stretching it.

In any case, applications launched via exec-once in autostart.conf were failing to start properly, causing multiple issues:

1. Blocking issues: uwsm-app blocks waiting for launched apps to exit, but daemons (waybar, mako, hypridle, etc.) never exit, causing subsequent apps in the chain to never launch.

2. Pipe bottleneck: uwsm-app uses named pipes for IPC with a daemon. According to UWSM docs, it's "intended for interactive launching, as it can fail on simultaneous requests." During autostart, 8+ apps launch simultaneously, causing pipe collisions that result in "App failure: Received empty command!" notifications.

3. Incomplete launches: Only the first app (hypridle) would launch, while waybar, swaybg, and others would fail silently or error out.

Attempted fixes that didn't work:

• Using && chaining: Failed if any app failed
• Using ; chaining: Still blocked on daemon apps that never exit
• Using & backgrounding: Caused pipe collisions and "empty command" errors

Root cause: uwsm-app is designed for interactive app launching (clicking icons, running commands manually), not for batch autostart scenarios.

Created omarchy-app wrapper that:

1. Calls systemd-run directly, bypassing the uwsm-app pipe bottleneck
2. Uses the same systemd integration (app-graphical.slice, proper scopes)
3. Returns immediately without blocking on daemon apps
4. Handles parallel execution without race conditions

This gives us clean syntax:

  exec-once = omarchy-app waybar

Instead of verbose:

  exec-once = systemd-run --user --scope --slice=app-graphical.slice \
    --unit=app-Hyprland-waybar.scope --collect -- waybar

• Use omarchy-app for autostart (simultaneous launches)
• Continue using uwsm-app for interactive launching (app icons, commands)

All autostart applications now launch reliably on every boot and relaunch:

• No blocking issues
• No "App failure" notifications
• No pipe collisions
• Waybar, swaybg, and all other apps start successfully

[dhh]

Nice. Let's use omarchy-launch-service instead of omarchy-app.

[woopstar]

this is fixed in next release of uswm app. We had an earlier pr or issue on this. Uswm-App should be able to launch simultainiosly now using a mutex lock