## Description

The screensaver interrupts video playback. Playing a video in a Firefox-based browser does not hold off idle, so the screensaver appears after `idle.screensaver` (2.5 min by default) and the lock screen follows at 5 min.

The shell's idle service is not at fault — `shell/plugins/services/idle/Service.qml` already sets `IdleMonitor { respectInhibitors: true }`, so a Wayland idle inhibitor would suppress it correctly. The problem is that the browser never creates one.

## Root cause

`org.freedesktop.impl.portal.Inhibit` is routed to a backend that cannot work under Omarchy:

1. `install/omarchy-base.packages` installs `xdg-desktop-portal-gtk`, which is the only installed backend advertising `org.freedesktop.impl.portal.Inhibit` (`hyprland.portal` does not list it).
2. Omarchy ships no `portals.conf`, so `xdg-desktop-portal` falls back to the GTK backend for `Inhibit` as a last resort.
3. The GTK backend's `Inhibit` forwards to `org.gnome.SessionManager`, then `org.freedesktop.ScreenSaver`. Neither exists under Omarchy — `grep -rn "org\.freedesktop\.ScreenSaver" /usr/share/omarchy/` is empty, and nothing owns that bus name.

So every inhibit request fails. From the journal, at exactly the moments the screensaver fired:

```
xdg-desktop-portal[1449]: A backend call failed: Inhibiting other than idle not supported
xdg-desktop-portal-gtk[1587]: Backend call failed: Cannot invoke method; proxy is for the
  well-known name org.freedesktop.ScreenSaver without an owner, and proxy was constructed
  with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
```

interleaved with:

```
omarchy-shell[1397]: omarchy idle 2026-09-06T00:03:02.573Z idle-monitor: idle
omarchy-shell[1397]: omarchy idle 2026-09-06T00:03:02.573Z idle-cycle-start: screensaver=150 lock=300
```

Firefox tries the portal first and only falls back to the Wayland `zwp_idle_inhibit_manager_v1` protocol when the interface is **absent**, not when the call **fails** (see [Mozilla bug 1877022](https://bugzilla.mozilla.org/show_bug.cgi?id=1877022) and [labwc discussion #1503](https://github.com/labwc/labwc/discussions/1503)). Advertising a broken `Inhibit` therefore shadows the path that actually works. `libxul.so` does export `zwp_idle_inhibit_manager_v1`, so the working path was available the whole time.

This is the same class of bug as `migrations/1784508556.sh` ("on Hyprland the xdg-desktop-portal Secret backend has no provider and fails").

## Steps to reproduce

1. Play a video in a Firefox-based browser (Zen, Firefox, LibreWolf) on a default Omarchy install.
2. Don't touch the mouse or keyboard.
3. The screensaver appears after 2.5 minutes, mid-video.

Confirm no inhibitor is being held:

```bash
journalctl --user --since "10 min ago" | grep -E "omarchy idle|portal"
```

## Expected

A playing video holds off the screensaver and the lock screen, without the user having to hit Stay Awake (`Super + Ctrl + I`) manually. The manual currently documents that toggle as the answer for long videos, which reads as a workaround for this gap.

## Fix

Ship a `hyprland-portals.conf` that removes the unusable interface, so browsers fall through to the Wayland protocol that Hyprland and the Omarchy shell already honor:

```ini
[preferred]
default=hyprland;gtk
org.freedesktop.impl.portal.Inhibit=none
```

Verified on this machine: after applying it and restarting the browser, `busctl --user call org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Inhibit Inhibit "sua{sv}" "" 8 0` returns `No such interface`, and video playback now suppresses the screensaver.

Nothing regresses, because the portal `Inhibit` path failed 100% of calls before — both of its backends are structurally absent on Omarchy.

PR follows.

## Related: `org.freedesktop.ScreenSaver` is unowned

Worth considering separately. Many applications call `org.freedesktop.ScreenSaver` directly rather than going through the portal (Steam, LibreOffice presentation mode, various Electron apps). On Omarchy that name has no owner, so those inhibit requests are silently dropped too. Having `omarchy-shell` own it and map `Inhibit`/`UnInhibit` onto the existing stay-awake mechanism would fix that broader class, and would also make the GTK portal backend work. Happy to open a separate issue if that's of interest.

## System

- Omarchy 4.0.2-1
- Kernel 7.1.9-arch1-2
- Hyprland 0.56.2
- CPU: AMD Ryzen 7 2700X
- GPU: NVIDIA GA104 [GeForce RTX 3060 Ti]
- xdg-desktop-portal 1.22.1-2, xdg-desktop-portal-gtk 1.15.3-1, xdg-desktop-portal-hyprland
- Browser: Zen 1.21.16b (Firefox-based)