### System details

- Omarchy `4.0.2-1`, Arch Linux, kernel `7.1.9-arch1-2`
- Hyprland `0.56.2-1`, UWSM `0.26.7-1`, systemd `261.2-1`
- CPU: AMD Ryzen AI Max+ 395; GPU: AMD Radeon 8060S / Strix Halo
- Display: LG ultrawide, `3440x1440` at approximately 100 Hz, connected as `DP-1`, scale `1`
- Affected app verified here: Spotify `1:1.2.96.518-2`, running through XWayland

### What's wrong?

After reducing monitor scaling to 100% using Omarchy's scaling controls, the monitor and saved GTK scaling configuration were both `1`, but the systemd user manager still exported `GDK_SCALE=2`. Spotify opened with an oversized interface. Synchronizing the activation environment to `1` and reopening Spotify through the normal launcher restored the correct size, without adding any Spotify-specific flags or changing its saved zoom.

#### Observed state before the workaround

`hyprctl -j monitors` reported `DP-1`, `3440x1440`, `scale: 1`.

`~/.config/hypr/monitors.lua` contained:

```lua
local omarchy_gdk_scale = 1
local omarchy_monitor_scale = 1

hl.env("GDK_SCALE", tostring(omarchy_gdk_scale))
hl.monitor({ output = "", mode = "preferred", position = "auto", scale = omarchy_monitor_scale })
```

However:

```console
$ systemctl --user show-environment | rg '^GDK_SCALE='
GDK_SCALE=2
```

The diagnostic terminal's own environment had `GDK_SCALE=1`. GNOME's text-scaling factor was `1.0`. Spotify's command line was simply `/opt/spotify/spotify`, with no scale override. Its interface was visibly approximately twice the intended size.

The local `monitor-scaling.log` records scale changes through the compositor, including a reduction from `2` through `1.6` and `1.25` to `1`. The configuration stayed at `1`, while the user manager retained `2`.

#### Steps to reproduce

1. Start an Omarchy session with `GDK_SCALE=2` in the app-launch environment, as supplied by the stock monitor configuration. Confirm it with `systemctl --user show-environment`.
2. Reduce the monitor to 100% with the scale-down shortcut or `omarchy hyprland monitor scaling 1`, using the stock-style `monitors.lua` that the command updates.
3. Confirm that the live monitor scale and both saved scale variables are now `1`.
4. Query `systemctl --user show-environment` again. On this installation it retained `GDK_SCALE=2`.
5. Launch an affected application such as Spotify through the normal app-launch path and compare its size after applying the workaround below.

#### Expected behavior

Changing scaling should synchronize the relevant environment used for subsequent application launches. Once the monitor and saved GTK scale are `1`, newly launched apps should receive the corresponding value without requiring a full logout or an undocumented environment refresh. Existing apps may still need to be restarted.

#### Confirmed workaround

```bash
dbus-update-activation-environment --systemd GDK_SCALE=1
```

After this, the user manager reported `GDK_SCALE=1`. Reopening Spotify with `uwsm-app -- /usr/bin/spotify` restored the correct interface size, verified with before/after screenshots. Its command line still had no scale flags.

#### Suspected cause

In the installed `bin/omarchy-hyprland-monitor-scaling`, `set_scale()` updates the live monitor and persists `omarchy_gdk_scale` in `monitors.lua`, but does not update the systemd/D-Bus activation environment. The environment imports in `default/hypr/autostart.lua` run on `hyprland.start` only. This appears to leave the launch environment at its login-time value after a scale change.

The stock 200% default makes this particularly noticeable on a display used at 100%. The failure reported here is the stale launch environment after correcting the scale.

Related reports: #5523 discusses a configured GDK scale not being respected on Omarchy 3; #7021 discusses the stock 200% value and XWayland scaling. This report adds the measured user-manager mismatch and a verified activation-environment workaround on Omarchy 4.0.2.