## What happened
Every suspend and hibernate cycle leaves the screen/session stuck (frozen, unresponsive) for roughly 85-90 seconds after the kernel has already resumed, before the session actually thaws and becomes usable again.

## Root cause
`/usr/lib/systemd/system-sleep/unmount-fuse`'s `post` branch already documents the exact failure mode it's trying to avoid:

```bash
if [[ $1 == "post" ]]; then
  # Run in background — user.slice is still frozen at this point, so a
  # synchronous restart would block the thaw for up to 90 seconds.
  (
    sleep 5
    for uid_dir in /run/user/*; do
      ...
      systemctl --user restart gvfs-daemon.service 2>/dev/null || true
      ...
    done
  ) &
fi
```

The backgrounding via `(...) &` does **not** actually detach the job from the sleep hook's process tree/cgroup, so systemd still waits on it before it will thaw `user.slice` — defeating the workaround the comment describes. In practice this means every resume hits the "up to 90 seconds" case, not just the intended edge case.

## Evidence
`journalctl -b` around a resume shows the exact gap, correlated with the backgrounded `sudo ... systemctl --user restart gvfs-daemon.service` call this hook spawns:

```
10:42:05  kernel: PM: suspend exit
10:42:10  sudo[...]: session opened for user wiaam ... systemctl --user restart gvfs-daemon.service
[85 second gap — nothing logged]
10:43:35  systemd[1]: user.slice: Unit now thawed.
10:43:35  systemd[1]: user-1000.slice: Unit now thawed.
10:43:35  systemd[1]: Finished System Suspend.
```

Reproduced identically across a plain suspend and a hibernate cycle on the same machine (both showed the ~85-90s gap between kernel resume and the thaw/"Finished System Suspend").

## Suggested fix
Hand each restart to `systemd-run` as an independent transient unit instead of a shell background job, so it runs fully outside this script's process tree and cannot block the thaw:

```bash
if [[ $1 == "post" ]]; then
  for uid_dir in /run/user/*; do
    uid=$(basename "$uid_dir")
    if [[ -S $uid_dir/bus ]]; then
      systemd-run --quiet --unit="omarchy-gvfs-restart-$uid-$$" \
        /bin/bash -c "sleep 5; sudo -u '#$uid' env DBUS_SESSION_BUS_ADDRESS=unix:path=$uid_dir/bus XDG_RUNTIME_DIR=$uid_dir systemctl --user restart gvfs-daemon.service" \
        2>/dev/null || true
    fi
  done
fi
```

I've applied this locally (in place of the packaged script) and confirmed resume is immediate afterward, with the gvfs restart still completing successfully in the background a few seconds later.

## Steps to reproduce
1. Suspend (or hibernate) the machine.
2. Resume.
3. Screen/session stays stuck for ~85-90 seconds before becoming responsive again.

## System details
- Omarchy version: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- systemd: 261 (261.2-1-arch)
- CPU: 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz
- GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics] (i915)
- Laptop, single integrated GPU (no hybrid/discrete graphics involved)


🤖 Generated with [Claude Code](https://claude.com/claude-code)