Fix tiled windows positioned behind top bar on workspace move

[cagostino]

monitor_work_area() always queries the active workspace for work area geometry, even when tiling a window that just moved to a different workspace. when a window gets moved between workspaces, the workspace-changed signal fires and pop-shell detaches + reattaches the window to the new workspace's tiling tree. during that reattach, it calls monitor_work_area() to figure out where to place the window — but since the active workspace hasn't switched yet, get_work_area_for_monitor() returns geometry for the wrong workspace. depending on timing, this can return y=0 instead of y=panel_height, so the window gets tiled behind the top bar.

the fix adds an optional workspace_idx parameter to monitor_work_area() so callers that know which workspace they're targeting can pass it explicitly instead of relying on the active workspace. all tiling codepaths that have fork/workspace context (attach_to_monitor, update_toplevel, detach_window, smart gap recalculations) now pass the actual workspace index. callers that genuinely operate on the active workspace (launcher, snap, display readiness check) are left unchanged.

this also explains why the bug is intermittent — it depends on whether gnome has finished switching the active workspace by the time the tiling code runs.

fixes #1565

[jacobktm]

I haven't been able to recreate this issue before applying this PR in order to verify that this resolves the issue. I noticed that the OS in the referenced issue is pop 22.04 but this PR looks like it's targeting pop 24.04, are you also having this issue in pop 24.04 and if so is there a set of steps I could use to recreate it?

[jacobgkau]

@jacobktm It sounds like the issue's intermittent (sounds like a race condition). We can probably just regression test this since engineering approved the approach.

The PR targeting the Noble branch means this is for users of the extension on non-Pop distros (or would apply if someone's replaced COSMIC with GNOME on Pop).

[cagostino]

actually no it should be targeting 22.04, i don't know if this issue occurs on 24.04 so that is my bad for specifying that incorrectly.

[jacobgkau]

Ok. @cagostino Your earlier PR, #1808, was targeting the correct branch for 22.04 (master_jammy), but included a lot of unnecessary (and breaking) commits since it was based on the default master_noble branch. Can you rebase on master_jammy?

[cagostino]

yeah i'll get this worked out tn