Ignore stale client commits on floating resize

[jbms]

When a new view is mapped, criteria rules may configure its
geometry (e.g. resize set). This configuration sends a new
configure event to the client.

However, during the map event handling, we are still processing
the initial commit from the client. After the map event is
handled and the rule-configured geometry is applied via a
transaction, the compositor's commit handler (handle_commit)
continues.

For floating containers, handle_commit resizes the container to
match the client's committed buffer size. If it processes the
initial commit (which has the initial client size, not the
configured one), it overrides the configured geometry back to the
initial size.

To fix this, we introduce is_commit_stale helper which checks
if there is a pending or scheduled configure event with a newer
serial than the serial acknowledged by the current commit. If the
commit is stale, we ignore its size for resizing floating
containers, waiting instead for the client to acknowledge and
commit the newly configured size.

How to reproduce:

1. Register the for_window rule:
   swaymsg 'for_window [title="Scratchpad Test"] move scratchpad, resize set 500 500'

2. Start the client:
   foot -T "Scratchpad Test"

3. Query the scratchpad window geometry:
   swaymsg -t get_tree | jq '.. | select(.name? == "__i3_scratch") | .floating_nodes[] | select(.name == "Scratchpad Test") | .rect'

   On buggy versions, this will output the client's default size
   instead of the configured 500x500.

Additionally:

• Make wait_for_client_map test utility robust by searching
  all workspaces and the scratchpad for the mapped view, instead
  of just checking the focused view. This allows it to be used
  for windows that are moved to the scratchpad (and thus
  hidden/unfocused) immediately upon mapping.
• Update wayland-client.c to support dynamic resizing in tests.
• Add integration test tests/test_scratchpad_geometry.py to
  verify the fix.

[jbms]

Note: This also applies to sway, I opened a PR there also: swaywm/sway#9215

[dawsers]

Did you look at #115?