Games DB: micro-optimize scan — bsearch m3u refs + single-pass RebuildSystems

Surfaced by a games-DB design review (adversarially verified against source). Both are low-severity cleanups (they sit behind directory I/O), worth doing only if profiling flags them.

1. m3u membership is a per-file linear scan. LibretroGamesIsM3uReferenced() (include/raylib-libretro-games.h) TextIsEqual-scans the whole m3uRefs vector for every scanned file → O(files × refs) on disc-heavy libraries. m3uRefs is built once and never mutated during the scan, so sort it once (a small char* comparator wrapping LibretroGamesPathCmp) and binary-search it, mirroring the existing LibretroGamesFindCached. Keep the check ahead of the cache fast-path (a cached disc that becomes newly m3u-referenced must still be hidden).

2. RebuildSystems is O(entries × distinct systems). LibretroGamesRebuildSystems() linear-scans the systems vector per entry. Since systemId is already an interned pointer into the static table, tally counts into a fixed int[ALIAS_COUNT+1] in one pass (map each entry to its slot via the interned pointer / table index) and emit one LibretroGameSystem per nonzero bucket.

Start with LibretroGamesIsM3uReferenced() and LibretroGamesFindCached in include/raylib-libretro-games.h, then inspect LibretroGamesRebuildSystems() and the static system table. Confirm how m3uRefs and interned systemId values are built before changing the scan strategy. Done means both scans use the proposed single-pass or binary-search approach while preserving the cache-order behavior and system counts.