## Summary

After powering on two monitors sequentially (not simultaneously), Hyprland placed both outputs at the same logical position (`0x0`), causing them to fully overlap. Screen content displayed correctly as two separate images, but the mouse cursor appeared and moved simultaneously on both monitors — a bonus second cursor nobody asked for, perfectly in sync, like a mirror universe that only affects the pointer. Turns out both outputs believed they lived at `0x0`, so as far as Hyprland was concerned they were roommates.

## Expected behavior

Each monitor should be placed at its own non-overlapping position as configured, regardless of the order in which the monitors are powered on.

## Steps to reproduce

1. Configure two monitors in `~/.config/hypr/monitors.lua`, where one output has an explicit `position`, and the other relies on the wildcard rule's `position = "auto"`:
   ```lua
   hl.monitor({ output = "", mode = "preferred", position = "auto", scale = 1.25 })
   hl.monitor({ output = "DP-1", mode = "3840x2160@60", position = "0x0", scale = 2 })
   ```
2. Power off both monitors.
3. Power the monitors back on one after another (sequentially, not at the same time).
4. Observe `hyprctl monitors` — both outputs report `at 0x0,0`.
5. Observe the cursor: it is visible and moves identically on both screens at once, even though each screen renders separate desktop content.

## Workaround

Give every monitor an explicit, non-overlapping `position` in `monitors.lua` instead of relying on `"auto"` for any of them:

```lua
hl.monitor({ output = "DP-1", mode = "3840x2160@60", position = "0x0", scale = 2 })
hl.monitor({ output = "DP-2", mode = "2560x1440@60", position = "1920x0", scale = 1.25 })
```

After `hyprctl reload`, both monitors report distinct positions and the cursor no longer duplicates.

## Suspected cause

Race between the wildcard monitor rule's `position = "auto"` placement and the explicit rule for the other output, triggered specifically by monitors connecting/waking sequentially (as opposed to both being present at Hyprland start). Auto-placement for the second output appears to run before the explicit rule for the first has been applied, so both resolve to `0x0` — "auto" apparently means "first come, first served, and everyone's first."

## System details

- Omarchy version: 4.0.3-1
- Hyprland version: 0.56.2 (v0.56.2, commit `efb50993780079460b0cbed1363e2166a2de1d9f`)
- Kernel: 7.2.3-arch1-3
- GPU: NVIDIA GeForce RTX 4070 Ti (AD104), driver `nvidia`
- Session type: Wayland
- Monitors: Microstep MPG321CX OLED (DP-1, 3840x2160@60, scale 2) + Fujitsu Siemens P27-8 TE Pro (DP-2, 2560x1440@60, scale 1.25)

## Note

`omarchy debug --no-sudo --print` does not exist in this Omarchy version (4.0.3-1) — `omarchy commands --all` has no `debug` entry, so no diagnostic log/upload URL is attached.