### System details

ThinkPad X1 Carbon Gen 8 (20U9CTO1WW), Intel i7-10610U, Omarchy 4.0.2-1, kernel 7.1.9-arch1-2, systemd 261.2-1, fingerprint auth configured via `omarchy setup security fingerprint`

### What's wrong?

The clamshell gate makes `pam_exec` log an **error on every sudo and polkit
authentication**, because the gate's normal, expected outcome is a non-zero exit.

```
sudo[...]: pam_exec(sudo:auth): /usr/bin/omarchy-hw-laptop-closed failed: exit code 1
polkit-agent-helper-1[...]: pam_exec(polkit-1:auth): /usr/bin/omarchy-hw-laptop-closed failed: exit code 1
```

Nothing is malfunctioning. The gate works exactly as designed — this is only the log level.

### Why it happens

`omarchy-setup-security-fingerprint` installs this line into `/etc/pam.d/sudo` and
`/etc/pam.d/polkit-1`:

```
auth      [success=1 default=ignore] pam_exec.so quiet /usr/bin/omarchy-hw-laptop-closed
auth      sufficient pam_fprintd.so
```

And `omarchy-hw-laptop-closed` exits **1 when the lid is open**:

```bash
[[ $(< "$state") == *"closed"* ]] && exit 0
exit 1
```

Lid-open is the common case, so the common path is a non-zero exit, and `pam_exec` logs any
non-zero exit at `LOG_ERR`. `quiet` does not suppress this — it only stops the module from
passing the child's output into the PAM conversation.

### Scale

Over 30 days on this machine:

```console
$ journalctl --since "30 days ago" | grep -c "omarchy-hw-laptop-closed failed"
35          # 23 from sudo, 12 from polkit
```

That is **16% of all error-priority journal lines** (35 of 215) — the single most frequent
error-level message on the system. On the busiest day it fired 19 times.

### Why it is worth fixing rather than ignoring

`omarchy-debug` includes a `JOURNALCTL (CURRENT BOOT, WARNINGS+ERRORS)` section, and the bug
template asks reporters to attach its output. So this noise is carried into *every* Omarchy
bug report filed from a laptop with fingerprint auth configured, competing with whatever the
reporter is actually reporting.

### Suggested fix

Invert the sense of the helper used by PAM, so the common case exits 0:

```
auth      [success=ignore default=1] pam_exec.so quiet /usr/bin/omarchy-hw-laptop-open
auth      sufficient pam_fprintd.so
```

with a new `omarchy-hw-laptop-open` exiting 0 when the lid is open. Control flow is
equivalent:

| lid | current gate | proposed gate |
|-----|--------------|---------------|
| open | `1` -> `default=ignore` -> fall through to `pam_fprintd` (**logs error**) | `0` -> `success=ignore` -> fall through to `pam_fprintd` (silent) |
| closed | `0` -> `success=1` -> skip `pam_fprintd` -> password | `1` -> `default=1` -> skip `pam_fprintd` -> password (logs, but rare) |

To be clear about what I have and have not checked: the control-flow table is derived from
`pam.conf(5)` semantics (`ignore` = result does not affect the stack, continue; `N` = skip N
modules), not from a runtime test. I did not want to experiment on a live `sudo` auth stack.
Worth confirming with `pamtester` against a scratch service before merging anything.

Note the existing helper cannot simply be inverted in place — its callers split into two
groups with opposite needs:

- **Boolean semantics, keep as-is:** `shell/plugins/polkit/PolkitAgent.qml:171`,
  `bin/omarchy-system-lid-close:16`, `bin/omarchy-hw-clamshell:7` all rely on
  `omarchy-hw-laptop-closed && ...`.
- **PAM gate sites, would move to the new helper:**
  `bin/omarchy-setup-security-fingerprint:19` (the shared `fprintd_gate` string),
  `migrations/1784818437.sh:15`, and the `grep` patterns in
  `bin/omarchy-remove-security-fingerprint:11,17` would need to match both names.

Existing installs would need a migration to rewrite the two PAM files.

I am happy to open a PR if this direction is wanted — it is cosmetic, so I would rather
check first than send unsolicited churn across four files plus a migration.