## What happened

After every login (SDDM autologin -> Hyprland via uwsm), the login keyring
occasionally comes back empty: Chrome loses its "Chrome Safe Storage" secret
(so it treats the profile as untrusted and demands sign-in/verification
again), and Docker Desktop loses its stored credential-helper secret (so it
re-prompts to store credentials in the keychain again). This has now happened
to me repeatedly across separate days.

## Root cause found

`gnome-keyring-daemon` is started twice at login through two independent
paths that both race to open the same on-disk keyring file
(`~/.local/share/keyrings/Default_keyring.keyring`):

1. PAM session hook: `-session optional pam_gnome_keyring.so auto_start`,
   present in **both** `/etc/pam.d/sddm` and `/etc/pam.d/sddm-autologin`.
2. The packaged systemd user service `gnome-keyring-daemon.service`
   (`WantedBy=default.target`), which starts unconditionally at every user
   session in addition to being socket-activated.

Caught live in this boot's own journal, right at login:

```
gnome-keyring-daemon[1469]: keyring was in an invalid or unrecognized format: /home/USER/.local/share/keyrings/Default_keyring.keyring
gnome-keyring-daemon[1469]: keyring was in an invalid or unrecognized format: /home/USER/.local/share/keyrings/Default_keyring.keyring
```

When gnome-keyring hits this, it quarantines the file and silently creates a
brand-new **empty** default keyring, wiping every secret that was stored in
it (Chrome's Safe Storage key, Docker's stored credential, etc.). On disk I
can see the trail of previous casualties from earlier days:

```
~/.local/share/keyrings/stale-backup-20260828-211412/Default_keyring_1.keyring
~/.local/share/keyrings/stale-backup-20260828-211412/Default_keyring_2.keyring
```

`omarchy install/login/sddm.sh` already strips the `-auth`/`-password`
`pam_gnome_keyring.so` lines from `/etc/pam.d/sddm` specifically to avoid
creating a password-encrypted login keyring that conflicts with Omarchy's
passwordless `default-keyring.sh` design — but it leaves the `-session
... auto_start` line untouched in both `/etc/pam.d/sddm` and
`/etc/pam.d/sddm-autologin`, so the daemon is still double-started against
the systemd user service every login. That looks like the missing half of
that fix.

## Expected behavior

The keyring should be started exactly once per session, and its contents
should persist reliably across logins instead of occasionally being wiped.

## Steps to reproduce

1. Fresh Omarchy install/session with SDDM autologin enabled (default).
2. Store a secret via libsecret (e.g. log into Chrome, or let Docker Desktop
   store a registry credential).
3. Reboot repeatedly. Intermittently (not every time — it's a race), the
   keyring will come back empty and the app will re-prompt.
4. Confirm via `journalctl --user -b 0 | grep -i "invalid or unrecognized format"`.

## Proposed fix

Remove the redundant PAM session line so only the systemd user service
(which is already correctly socket-activated) manages the daemon:

```bash
sed -i '/-session.*optional.*pam_gnome_keyring\.so.*auto_start/d' /etc/pam.d/sddm /etc/pam.d/sddm-autologin
```

Happy to send a PR for this if maintainers agree with the diagnosis.

## System details

- Omarchy version: 4.0.1-1
- gnome-keyring: 1:50.0-1
- Kernel: 7.1.9-arch1-2
- Login flow: sddm (autologin) -> `uwsm start -g -1 -e -D Hyprland hyprland.desktop`
- No polkit authentication agent is running/installed on this system
  (unrelated to the bug, noted in case it's relevant to keyring prompt
  behavior elsewhere).