Draw a resizing window's decoration from the same rect as its content

Reported as the titlebar not resizing at the same time as the window, and
as resizing feeling cheap.

effective_frame_of returned the live drag target while a resize was active,
so the titlebar and border tracked the pointer while the client's actual
pixels were still whatever it last committed. The two disagreed for the
whole drag, and the decoration leading its own content is what reads as
broken.

It now returns the committed size anchored to whichever edge the drag is
holding still - exactly the rect the content occupies, since sync_geometry
positions it the same way, so the two agree by construction rather than by
timing. The consequence is that the frame sits one commit behind the
pointer instead of ahead of its own content. That is the trade every other
compositor makes, and it is the right way round: a frame glued to its
content and slightly behind the cursor reads as solid.

The committed-size correction was extracted into committed_frame so the
resize path and the ordinary path share it rather than having two versions
that can drift, and so the resize path is no longer short-circuited by the
pending-configure branch, which fires constantly during a drag precisely
because every tick sends a configure.

533 tests pass, clippy clean. The arithmetic is covered where it is
testable; how it feels mid-drag is a judgement only real hardware can make,
and a nested drag did not reproduce a clean enough scenario to claim it.

0 files changed, 0 insertions, 0 deletions