Fix crash when drag detaching Chrome tabs

[chromakode]

Fixes #1069

When detaching tabs from Chrome by dragging them out of the current window, PaperWM calls layoutGrabColumn with a null selectedWindow, causing the layout recalculation to crash.

This PR changes it to pass inGrab.window directly for the grabWindow parameter, which seems to match the if predicate better too.

I also fixed an incidental crash when formatting the error in layoutGrabColumn when null gets passed in.

Finally, when testing this out, I noticed that layoutGrabColumn positions the detached window with a somewhat arbitrary seeming y position (seems to be based on where it was created on detach):

Screencast.From.2025-10-13.17-59-33.mp4

Adding inGrab.dnd to the predicate uses the normal layout function and prevents this behavior:

Screencast.From.2025-10-13.17-58-00.mp4

I don't yet fully understand the cases where layoutGrabColumn is important, but it seems like the gap preservation only matters when we're in the fully engaged "DnD grab" where the window is pulled out of the layout and being moved to a new tiled position.

There's still a little funkiness I've seen occasionally in testing, but this change prevents the stateful layout corruption described in the original issue.

[chromakode]

When a Chrome tab is being detached in this way, inGrab.begin / inGrab.beginDnD never get called. I explored calling them, because ideally the new detached window you're grabbing would enter the "DnD grab" where you can select a new tiled position. However, there seemed to be more going on here, because upon release the detached window doesn't end up in the tiled position selected.

Perhaps Chrome is doing something more here and recreating the window upon grab end.

I'd love to get to the bottom of this but wanted to keep the scope of this PR small.

[yarikoptic]

@chromakode in the context of

• Integration testing under "fake" GNOME instance on github CI #1098

do you think there is some way to "script" triggering such a bug e.g. with https://github.com/jordansissel/xdotool or alike?

[chromakode]

@chromakode in the context of

• Integration testing under "fake" GNOME instance on github CI #1098

do you think there is some way to "script" triggering such a bug e.g. with https://github.com/jordansissel/xdotool or alike?

A simple approach could be to capture snapshots of the mutter events received in PaperWM and have a way to replay them on the core code. That'd make smaller unit tests that run faster (and are potentially less flaky than setting up a whole Wayland environment) at the cost of being potentially less resilient if Mutter or Wayland change their event format. That kind of test would cover this bug well.

[yarikoptic]

sounds interesting but would it make it wayland specific if I got it right?

even if not a full way to do scripting of tests, I think it might be useful to get documentation (and/or helpers) on how to capture/replay so user issues could be attempted to be reproduced.