Fix interactive-resize border/shadow lag without the OOB risk that sank the first attempt

effective_frame_of now returns the live drag target while a window is
being interactively resized (same change as the reverted first attempt),
but two things make it safe this time instead of reintroducing the
out-of-bounds texture sample that reversion was for:

- Every src crop rect built from a window's frame width in udev/render.rs
  and winit/render.rs (titlebar, top border strip, bottom border strip)
  is now clamped against DecorationSignature's own recorded width/
  border_width - the bitmap's actual last-built size - before reaching
  MemoryRenderBufferRenderElement::from_buffer, which does not itself
  validate src against the real texture size. This is a structural floor
  independent of timing, not a repeat of the previous unsafe approach.
- handle_pointer_position now calls redraw_decoration_buffer once per
  resize motion event (throttled to 60Hz via a new
  CompState::resize_redraw_at), closing the lag at its source instead of
  only catching up on the next real client commit. This also fixes the
  shadow bitmap's identical commit-vs-live-position gap for free, since
  redraw_decoration_buffer rebuilds all three bitmaps together.

Updates the TODO.md entry for this bug with the full before/after.

1 files changed, 1 insertions, 0 deletions

diff --git a/crates/wayland/src/winit/connect.rs b/crates/wayland/src/winit/connect.rs
index c748ef4..30eaaf8 100644
--- a/crates/wayland/src/winit/connect.rs
+++ b/crates/wayland/src/winit/connect.rs
@@ -161,6 +161,7 @@ impl WaylandPlatform {
             border_top_decorations: HashMap::new(),
             border_bottom_decorations: HashMap::new(),
             decoration_signatures: HashMap::new(),
+            resize_redraw_at: None,
             hovered_titlebar_button: None,
             shadow_buffers: HashMap::new(),
             rounded_corners_program,