menu/ozone: silence UBSan float-to-unsigned conversion in entries draw

UBSan-instrumented run reported:

  menu/drivers/ozone.c:6401:13: runtime error: -10.0781 is outside
  the range of representable values of type 'unsigned int'

Origin: the value-text y argument to ozone_draw_entry_value() is
declared as unsigned, but the y expression at the call site is

    y                                                 /* size_t */
    + ozone->dimensions.entry_height / 2              /* int    */
    + ozone->fonts.entries_label.line_centre_offset   /* int    */
    + scroll_y                                        /* float  */

The trailing float promotes the whole sum to float.  scroll_y is
clamped to (-inf, 0] (lines 10435-10436), so when the topmost
partially-visible row's vertical centre lands above the header
boundary -- reachable during pointer/wheel scrolling -- the sum
goes slightly negative (UBSan saw -10.0781).  The implicit
float-to-unsigned conversion of a negative is undefined per C11
6.3.1.4 p1.

Runtime impact: low.  Every modern compiler wraps the conversion
to ~UINT_MAX in practice; ozone_draw_entry_value then promotes
that back to float as it forwards into gfx_display_draw_text(),
producing a coordinate around 4.29e9 that the rasteriser clips
off-screen.  The value text just doesn't render that frame,
visibly matching the off-screen-row case it would have hit on
the next frame anyway.

Fix: cast the sum through int (defined conversion for the range
these screen coordinates occupy: small positive y plus a bounded
negative scroll_y) so the negative case wraps in a defined
manner rather than triggering UB.  Matches the
(int)((float)y + scroll_y) idiom already used at lines 3581,
3595, 5970 and 5985 in the same file for sibling y arguments
that are signed-typed at the callee.

Also folds entry_height / 2 -> entry_height / 2.0f for
consistency with the surrounding label and sublabel y
expressions at lines 6319 and 6346, which already use float
division -- relevant only on the rare odd entry_height where
integer division would round half a pixel below the float
result.

Author: LibretroAdmin

menu/drivers/ozone.c

@@ -6398,10 +6398,28 @@ static void ozone_draw_entries(
                   + x_offset
                   + entry_width
                   - ozone->dimensions.entry_icon_padding,
-            y
-                  + ozone->dimensions.entry_height / 2
+            /* The y arg is unsigned but the sum below evaluates to
+             * a float because of scroll_y, which is clamped to <= 0
+             * (see lines 10435-10436).  When the row's vertical
+             * centre lands above the visible top -- reachable
+             * during pointer/wheel scrolling whenever the topmost
+             * partially-visible row's value text would draw above
+             * the header -- the float value can be slightly
+             * negative (UBSan reported -10.0781).  Implicit
+             * float-to-unsigned conversion of a negative is UB
+             * (C11 6.3.1.4 p1); silently wraps to ~UINT_MAX in
+             * practice, which the renderer then implicit-converts
+             * back to float as a huge off-screen coordinate, so
+             * the text just fails to draw rather than corrupting
+             * anything.  Cast through int -- well-defined for the
+             * range these screen coords occupy -- so the negative
+             * case wraps in a defined manner instead.  Matches the
+             * (int)((float)y + scroll_y) idiom used at lines 5970,
+             * 5985, 3581, 3595. */
+            (int)((float)y
+                  + ozone->dimensions.entry_height / 2.0f
                   + ozone->fonts.entries_label.line_centre_offset
-                  + scroll_y,
+                  + scroll_y),
             alpha_uint32,
             &entry,
             mymat);