**What happened**

A fresh Omarchy 4.x install has zero Qt5 packages. SDDM picks its greeter binary from
the theme's `metadata.desktop`: a theme carrying `QtVersion=6` gets
`/usr/bin/sddm-greeter-qt6`, one without that key falls back to the Qt5 binary
`/usr/bin/sddm-greeter`. Of the four themes present on a default install, only
`omarchy` declares `QtVersion=6` — the other three ship with the `sddm` package itself:

```
$ for t in /usr/share/sddm/themes/*/; do printf "%-10s " "$(basename $t)"; grep -i "^QtVersion" "$t/metadata.desktop" || echo "(none)"; done
elarun     (none)
maldives   (none)
maya       (none)
omarchy    QtVersion=6

$ pacman -Q | grep -c '^qt5'
0
```

So the moment `/etc/sddm.conf.d/*.conf` names any theme other than `omarchy`, the
greeter cannot start:

```
sddm[923]: Loading theme configuration from "/usr/share/sddm/themes/maya/theme.conf"
sddm[923]: Greeter starting...
sddm-helper-start-wayland[1016]: "/usr/bin/sddm-greeter: error while loading shared libraries: libQt5Quick.so.5: cannot open shared object file: No such file or directory"
sddm-helper-start-wayland[1016]: wayland greeter finished 127 QProcess::NormalExit
sddm-helper-start-wayland[1016]: "(EE) could not connect to wayland server"
```

SDDM tears the Hyprland compositor down and retries, forever. The screen stays black
and there is no way to log in graphically.

```
$ ldd /usr/bin/sddm-greeter | grep 'not found'
	libQt5Quick.so.5 => not found
	libQt5Qml.so.5 => not found
	libQt5Network.so.5 => not found
	libQt5Gui.so.5 => not found
	libQt5Core.so.5 => not found

$ ldd /usr/bin/sddm-greeter-qt6 | grep -c 'not found'
0
```

**Why this stays hidden**

Autologin skips the greeter entirely, so a broken theme setting can sit on a machine
for weeks without symptom. Mine did: the theme had been `maya` since 30 Aug, sixteen
minutes after install, and I only found out when I removed
`/etc/sddm.conf.d/autologin.conf` during a security review. First boot after that:
permanent black screen.

That is the same masking mechanism as #10269, and it lands on the same people —
removing autologin is exactly what a security-conscious user does, and it is precisely
the action that detonates this.

**Omarchy already documents this failure mode**

`migrations/1785351479.sh` (Kvantum removal) guards against it explicitly:

```
# What this deliberately does NOT touch is qt5-wayland and qt5-declarative. On a
# machine whose sddm theme metadata predates QtVersion=6, those are what keep
# the Qt5 greeter able to start, and removing them is how you end up with no
# login screen. qt5-wayland is explicitly installed, so the -s cascade leaves it
# and the qt5-base beneath it alone.
```

The reasoning is right, but the premise does not hold here: `qt5-wayland` is **not**
explicitly installed — no qt5 package has ever been installed on this machine.

```
$ grep -aE "\[ALPM\] (installed|removed|upgraded) qt5" /var/log/pacman.log
(no output)
```

The migration protects a safety net that a 4.x install does not have. Its own stated
worst case ("that is how you end up with no login screen") is simply the default state.

**Expected**

Selecting a stock SDDM theme should not be able to leave the machine with no way to
log in.

**Steps to reproduce**

1. Fresh Omarchy 4.x install (no Qt5 packages).
2. Set the SDDM theme to a stock non-Omarchy one, e.g. `Current=maya` in
   `/etc/sddm.conf.d/99-omarchy-login.conf`.
3. Remove `/etc/sddm.conf.d/autologin.conf`.
4. Reboot. LUKS unlocks, then the screen stays black permanently.
   `journalctl -b -1 -u sddm` shows the `libQt5Quick.so.5` failure above.

**Suggested fix**

Any one of:

- Make the migration's assumption true: pull `qt5-declarative` + `qt5-wayland` into the
  base install, so the Qt5 greeter is always startable.
- Or drop the three Qt5-only stock themes, so nothing selectable is broken.
- Or guard the setting: on update, if the configured theme's `metadata.desktop` lacks
  `QtVersion=6` and no Qt5 greeter libraries are present, reset `Current=` to `omarchy`
  and say so.

The last is the cheapest and is self-healing for machines already in this state.

**One thing I cannot show**

I have no evidence that an Omarchy command wrote `Current=maya`. Grepping
`/usr/share/omarchy/bin` finds nothing that writes to `/etc/sddm.conf.d/`, so on this
machine it was most likely set by hand. This report is about the resulting fragility,
not about how the value got there.

**System details**

- Omarchy: 4.0.2-1
- omarchy-settings: 4.0.2-1
- sddm: 0.21.0-7 · hyprland: 0.56.2-1
- Kernel: 7.1.9-arch1-2
- CPU: Intel Core i7-8565U
- GPU: Intel UHD Graphics 620 (WhiskeyLake-U GT2)
- Disk: LUKS-encrypted btrfs root
- Qt5 packages installed: 0