## What happened

On a 3-monitor setup with mixed resolutions, floating "maximized" windows are
consistently positioned 30px too far left and 2px too far up relative to
their monitor's actual origin. The window *size* correctly matches the
target monitor's resolution, but the *position* is always
`monitor_position - (30, 2)`. This causes the left ~30px of the window to
render outside the monitor's bounds — on the leftmost monitor this region is
completely off the virtual desktop (invisible), on the other monitors it
bleeds into the neighboring monitor's render area. A corresponding ~30px gap
is left unfilled on the right edge of the monitor.

This reproduces both via the app's own native maximize control (relevant
because Omarchy's default window rule `suppress_event = "maximize"` blocks
Hyprland from handling that request itself, so the client-side geometry and
the compositor-side floating geometry can end up out of sync) and via
Hyprland's own floating-window placement when toggling a window to floating
with SUPER+T.

Hyprland's own `fullscreen` dispatch (SUPER+F) is unaffected and correctly
fills each monitor exactly — only the floating "maximize-sized" placement
path is wrong.

## Expected behavior

A maximized/full-size floating window's `at` should equal the target
monitor's exact origin (or origin + gaps_out, consistently), with `size`
matching the monitor's usable area.

## Actual behavior

`at` is consistently offset by `(-30, -2)` from the monitor's origin,
regardless of which monitor or which monitor's resolution, causing the
window's left edge to be clipped/hidden.

## Steps to reproduce

1. Configure 3 monitors side by side with mixed resolutions, e.g.:
   ```lua
   hl.monitor({ output = "DP-3", mode = "1920x1080@60", position = "0x0", scale = 1 })
   hl.monitor({ output = "DP-2", mode = "2560x1440@144", position = "1920x0", scale = 1 })
   hl.monitor({ output = "DP-1", mode = "1920x1080@60", position = "4480x0", scale = 1 })
   ```
2. Open a window (e.g. Chromium) on any of these monitors.
3. Either click the app's own native maximize control, or float the window
   and toggle SUPER+T to floating.
4. Run `hyprctl clients` and compare `at:` to the monitor's configured
   `position` from `hyprctl monitors all`.

## Evidence

`hyprctl monitors all` (matches `~/.config/hypr/monitors.lua` exactly, no
gaps/overlaps):

```
DP-3 (ID 2): [email protected] at 0x0
DP-2 (ID 1): [email protected] at 1920x0
DP-1 (ID 0): [email protected] at 4480x0
```

`hyprctl clients` after maximizing/floating a window on each monitor:

| Monitor | Monitor position | Monitor resolution | Window `at` | Window `size` | Offset from monitor origin |
|---|---|---|---|---|---|
| DP-3 (left)   | 0,0    | 1920x1080 | -30,-2   | 1920x1080 | (-30,-2) |
| DP-2 (center) | 1920,0 | 2560x1440 | 1890,-2  | 2560x1440 | (-30,-2) |
| DP-1 (right)  | 4480,0 | 1920x1080 | 4450,-2  | 1920x1080 | (-30,-2) |

The offset is identical in every case, independent of monitor resolution or
position — strongly suggesting a fixed miscalculation in the floating
maximize-size placement code rather than a per-monitor issue.

## System details

- Omarchy version: 4.0.0-1
- Hyprland version: 0.56.2-1 (commit efb50993780079460b0cbed1363e2166a2de1d9f)
- GPU: NVIDIA GeForce RTX 2070 SUPER (driver 610.57.04, nvidia_drm modeset=1
  via /etc/modprobe.d/nvidia.conf), all 3 monitors connected to this GPU.
  Secondary AMD Raphael iGPU (amdgpu) present but has no displays attached.
- general:gaps_out = 10, general:gaps_in = 5, general:border_size = 2,
  decoration:rounding = 0 (none of these obviously account for a 30/2 offset)
- `hyprctl configerrors` reports no errors