fix: add bounds clamping in c_display::fill_rect() for negative coordinates

[srpatcha]

Fix buffer underflow from negative coordinates in c_display::fill_rect()

Problem

c_display::fill_rect() in src/core/display.h computes framebuffer offsets using y * _width + x0 without validating that coordinates are non-negative. Negative coordinates cause out-of-bounds memory writes to the framebuffer, potentially corrupting memory or causing crashes.

Root Cause

The child class c_surface::fill_rect() properly clamps coordinates, but the base class c_display::fill_rect() does not. While the inner loop checks x < _width and y < _height for upper bounds, it does not check for negative values. The framebuffer pointer arithmetic &((unsigned short*)m_phy_fb)[y * _width + x0] will produce an address before the buffer when x0 or y is negative.

Fix

Added bounds clamping at the start of the direct framebuffer path (after the driver delegation checks):

• Clamp x0, y0 to minimum of 0
• Clamp x1, y1 to maximum of width-1, height-1
• Early return if the clamped rect is empty (x0 > x1 or y0 > y1)

Testing

• Call fill_rect() with negative coordinates (e.g., fill_rect(-10, -5, 50, 50, color)) and verify no crash occurs.
• Verify normal positive-coordinate rectangles still render correctly.

Impact

Affects any GuiLite application that passes negative coordinates to the base display class's fill_rect. This is a memory safety issue.

[srpatcha]

Friendly ping — this adds bounds clamping in c_display::fill_rect() for negative coordinates to prevent out-of-bounds memory access. Ready for review.