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.

0 files changed, 0 insertions, 0 deletions