Fix UI freeze: clamp FPSLimit frame-limiter underflow in draw_screen()

[szb78]

Fix Uint32 underflow in manual FPS limiter causing permanent UI freeze

Fixes #98

Problem

When VSync=false and an FPSLimit is set, the manual frame limiter in
draw_screen() (src/launcher.c) computes the sleep time as an unsigned
subtraction:

Uint32 sleep_time = refresh_period - (SDL_GetTicks() - ticks.main);
if (sleep_time > 0)
    SDL_Delay(sleep_time);

Whenever a frame overruns its target interval — which happens on any blocking
texture load, e.g. returning from a launched application, navigating menus, or a
submenu transition — (SDL_GetTicks() - ticks.main) exceeds refresh_period.
The Uint32 subtraction then underflows to a huge value (~4.29e9), so
SDL_Delay() sleeps for ~49 days and the UI freezes permanently. Because the
process is alive but hung, a watchdog/restart loop can't recover it — it needs a
power cycle.

Fix

Compare before subtracting, so the delay is only computed (and applied) when the
frame finished early:

Uint32 elapsed = SDL_GetTicks() - ticks.main;
if (elapsed < refresh_period)
    SDL_Delay(refresh_period - elapsed);

When a frame overruns, we simply skip the delay and proceed to the next frame.

Testing

Built from this branch and deployed on an HP T640 (Ubuntu 24.04, SDL 2.30).
Reproduced the freeze reliably on the original binary with VSync=false +
FPSLimit=15 by launching an app and returning to the menu; the patched binary
runs through the same flow — startup, submenu in/out, and app launch-and-return —
with no freeze.

With the FPS limiter now working safely, idle resource usage on the static menu
also dropped sharply:

• GPU utilization: 12% → 6%
• System load average: 1.04 → 0.02