1Password refuses XDG_RUNTIME_DIR when the directory has a POSIX ACL (mask misread as group permission)

On Raspberry Pi OS (Debian 13 trixie, aarch64), 1Password 8.12.34 logs this three times on every launch:
The directory is **not** actually group-accessible. It carries a POSIX ACL:

```
$ stat -c '%a' /run/user/1000
770

$ getfacl -p /run/user/1000
# owner: pi
# group: pi
user::rwx
user:vnc:rwx      <- wayvnc runs as user 'vnc' and needs the Wayland socket
group::---        <- real group permission: NONE
mask::rwx         <- what stat() reports in the group field
other::---
```

`group::` is `---`. The `770` that `stat()` returns is the **ACL mask**, which is what the group bits display as on any file with an extended ACL — standard POSIX ACL behaviour, not a misconfiguration. Only `pi` and `vnc` can enter the directory.

The permission check appears to test `st_mode & 0o077` and refuse when any bit is set. On any system that puts an ACL on the runtime directory, that is a **false positive**.

**This is not an exotic setup.** Raspberry Pi OS adds this ACL automatically whenever the built-in VNC server is enabled, so it affects that platform by default — and any distribution that grants a helper user access to the user runtime directory this way.

**Observable consequences** beyond the log noise:

```
ERROR [1P:native-messaging/op-native-core-integration/src/lib.rs:874]
      Listener on SETTING_STATUS has been dropped, unable to communicate changes made to browser SLS setting
ERROR [1P:ssh/op-agent-controller/src/lib.rs:585]
      Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
```

Browser-integration and SSH-agent IPC listeners fail to bind. Single-instance detection also appears unreliable — clicking the launcher can spawn a second instance rather than raising the existing window.

**Please do not suggest `chmod 700` as the workaround.** On this platform that clears the ACL mask and **cuts the VNC server off from the Wayland socket**, losing remote desktop access to the machine. It is the fix every search result offers and it is actively harmful here. There is no user-facing setting to override the check, so there is currently no safe workaround at all.

**Suggested fix:** when the mode looks permissive, check for an ACL (`acl_get_file`) and evaluate the effective entries before refusing — or at minimum test the real `group::` permission rather than the mask.

**Environment**

| | |
|---|---|
| 1Password | 8.12.34 (Linux, arm64) |
| OS | Raspberry Pi OS / Debian GNU/Linux 13 (trixie), aarch64 |
| Hardware | Raspberry Pi 500+ |
| Session | Wayland (labwc 0.9.8 / wlroots) |
| Reproducibility | Every launch, including after a clean reboot |

---