### System details

AMD 9800X3D, NVIDIA 2080Ti, Omarchy 4.0.1-1, SDL 3.4.14

### What's wrong?

On Omarchy 4.0.1-1, running a minimal SDL3 application using the Wayland backend causes the session to lock immediately when the application exits.

This is 100% reproducible with a minimal SDL program and does not require a crash or abnormal termination.

The behavior does **not** occur when using SDL's X11 backend.

I have also confirmed that setting `SDL_HINT_VIDEO_ALLOW_SCREENSAVER` to `1` before `SDL_Init()` prevents the problem.

### System

* Omarchy: `4.0.1-1`
* Hyprland: `0.56.2` (`efb50993780079460b0cbed1363e2166a2de1d9f`)
* SDL3: `3.4.14`
* Wayland session
* Quickshell/Omarchy idle service
* Lock screen timeout **disabled** through Omarchy settings (*triggers*)

### Steps to reproduce

Use a minimal SDL3 program such as:

```cpp
#include <SDL3/SDL.h>

int main()
{
    if (!SDL_Init(SDL_INIT_VIDEO))
        return 1;

    SDL_Window *window = SDL_CreateWindow(
        "SDL idle test",
        800,
        600,
        0
    );

    if (!window)
        return 1;

    SDL_Delay(30000);

    SDL_DestroyWindow(window);
    SDL_Quit();

    return 0;
}
```

Compile and run it using the normal Wayland backend:

```bash
g++ test.cpp $(pkg-config --cflags --libs sdl3) -o test
SDL_VIDEODRIVER=wayland ./test
```

Then:

1. Start the program.
2. Do not interact with the mouse or keyboard.
3. Wait for the 30-second delay to finish.
4. When the SDL application exits, the Omarchy lock screen appears immediately.

The lock happens essentially at the exact moment the SDL process exits.

### Additional observations

The problem is specific to SDL's Wayland backend.

Forcing SDL to use X11:

```bash
SDL_VIDEODRIVER=x11 ./test
```

does **not** cause the lock when the application exits.

The problem is also independent of the application crashing. A completely normal `SDL_Quit()` followed by process termination reproduces it.

### Journal output

During reproduction, `journalctl --user -f` shows:

```text
idle-monitor: active
idle-monitor: idle
idle-cycle-start: screensaver=0 lock=0
process-start: screensaver [[ $(omarchy-shell lock isLocked 2>/dev/null) == "true" ]] || omarchy-launch-screensaver
lock-system: lock-timeout-immediate
process-start: lock omarchy-system-lock
lock-requested
lock-pending: screen-stabilizing
process-exit: screensaver exitCode=1 status=0
process-exit: lock exitCode=0 status=0
```

In particular, the idle monitor transitions to `idle` immediately after the SDL application's Wayland resources are destroyed, followed by the immediate lock.

### Confirmed workaround

Adding this **before `SDL_Init()`** prevents the problem:

```cpp
SDL_SetHint(SDL_HINT_VIDEO_ALLOW_SCREENSAVER, "1");
```

For example:

```cpp
int main()
{
    SDL_SetHint(SDL_HINT_VIDEO_ALLOW_SCREENSAVER, "1");

    if (!SDL_Init(SDL_INIT_VIDEO))
        return 1;

    // ...
}
```

With this hint enabled, the application can start and exit normally without triggering the lock.

### Suspected interaction

SDL disables the screensaver by default for video applications. On Wayland, SDL implements this using the Wayland idle-inhibit protocol.

The suspected sequence is therefore:

1. SDL starts using the Wayland backend.
2. SDL creates a Wayland idle inhibitor.
3. Omarchy's Quickshell `IdleMonitor` respects that inhibitor.
4. The SDL application exits.
5. SDL destroys the Wayland idle inhibitor.
6. Omarchy immediately observes the session as idle.
7. Because the configured lock timeout is effectively immediate in this state, `omarchy-system-lock` is invoked.

This would explain why:

* the problem only occurs with SDL's Wayland backend;
* it happens exactly when the SDL process exits;
* it does not require an SDL crash;
* X11 does not reproduce it;
* `SDL_HINT_VIDEO_ALLOW_SCREENSAVER=1` completely prevents it.

I realize that SDL's use of the Wayland idle-inhibit protocol is intentional, so I'm not necessarily suggesting that SDL is doing anything wrong. The potentially problematic part appears to be the transition from "idle inhibited" to "idle" in Omarchy, particularly when the application releasing the inhibitor was the only thing preventing the idle state.

### Expected behavior

Destroying a Wayland idle inhibitor should allow the normal idle timer to resume, but exiting an application that used SDL's default screensaver inhibition should not unexpectedly lock the session immediately.

### Workaround

For SDL applications where screensaver inhibition is not desired:

```cpp
SDL_SetHint(SDL_HINT_VIDEO_ALLOW_SCREENSAVER, "1");
```

before `SDL_Init()`.

### Reproducibility

100% reproducible with the minimal SDL program above on my system.