### System details

AMD Ryzen 7 3700X, NVIDIA GeForce RTX 4070 Ti SUPER, Wayland; Omarchy 4.0.4-1 on CachyOS; Hyprland 0.56.2-4.1; kernel 7.2.9-1-cachyos; Qt 6.12.0.

### What's wrong?

Locking silently does nothing when `/etc/pam.d/omarchy-lock-password` is missing. This was observed on an existing installation after a system upgrade; the precise reason that the PAM file was absent has not been established.

The installed package provides `install/config/lockscreen-pam.sh`, which invokes `omarchy-apply-lock`, and that helper creates the PAM file. However, the running lock service had no password PAM configuration on this machine.

#### Reproduction

On an installation lacking `/etc/pam.d/omarchy-lock-password`:

1. Invoke `omarchy system lock` (or the default Super+Ctrl+L binding).
2. Observe that the desktop remains accessible, with no lock screen or error shown.
3. Query the shell directly:

```text
$ omarchy-shell lock lock
missing-pam

$ omarchy-shell lock status
{"locked":false,"requested":false,"pending":false,"sessionLocked":false,"secure":false,"realScreens":1,"passwordPam":false,"fingerprint":false,"authenticating":false,"lastEvent":"init","lastEventAt":""}
```

The installed `plugins/lock/Service.qml` deliberately refuses to lock without PAM:

```qml
function lock(): string {
  if (!root.passwordPamConfigured) return "missing-pam"
  if (!root.locked && !root.beginLock()) return "failed"
  return "ok"
}
```

But `bin/omarchy-system-lock` discards the result and continues:

```bash
omarchy-shell lock lock >/dev/null
```

The IPC wrapper only checks transport failures, so the `missing-pam` string is not propagated as a command failure. The public command returned exit status 0 while the session stayed unlocked.

#### Expected

A successful lock command should result in a secured session. When authentication configuration is missing, report the failure clearly and return nonzero, with guidance to restore the configuration using the existing helper. The upgrade/setup path should ensure the required PAM service exists.

#### Local recovery and limits

Creating a password PAM service using the system authentication stack changed `passwordPam` from `false` to `true`, without a shell restart. This confirms the missing-file gate; a full lock/unlock authentication cycle has not yet been verified.

The shell currently runs from a user-owned compatibility copy with QtQuick imports pinned to 6.11 to work around the separate Qt 6.12 `Color` collision (#14548). The lock service logic above is unchanged from the installed package. There is no evidence that the compatibility copy removed the PAM file.

The skill-documented `omarchy debug --no-sudo --print` command is unavailable in this installed package, so the relevant diagnostics are included inline. No screenshot is attached because the visible symptom is an unchanged, unlocked desktop containing private application content.