Fix Linux build on master: add missing CDebuggerApi::GetWarpSpeed() referenced by #114

[arekbr]

Sorry -- this one is on me. When I split the original branch into three PRs, the split went by file, and CDebuggerServerApi.cpp carried hunks belonging to two topics: the warp/get endpoint landed in #114, while the CDebuggerApi::GetWarpSpeed() method it calls stayed in the still-open #116. With #114 and #115 merged and #116 paused, master fails on Linux:

src/Remote/CDebuggerServerApi.cpp:112:47: error: 'class CDebuggerApi' has no
member named 'GetWarpSpeed'; did you mean 'SetWarpSpeed'?

This PR adds exactly that method -- declaration plus a trivial forward to the existing CDebugInterface::GetSettingIsWarpSpeed() -- and nothing else. Verified: master + this patch builds clean on Debian 13 / GCC 14. Once merged, #116 will be rebased so the hunk does not appear twice.

The macOS and Windows failures on the same CI runs are a different story and predate nothing in the merged code:

• macOS dies in MTEngineSDL's Libtool libMTEngineSDL.a step -- Apple libtool from the Xcode 26.6 runner image prints its Usage banner, i.e. it no longer accepts one of the passed flags. Neither merged PR touches MTEngineSDL or the Xcode project.
• Windows dies in bundled SDL headers: SDL_endian.h(40,1): error: definition of builtin function '_m_prefetch' -- a known bundled-SDL2-vs-newer-MSVC clash, again in files the PRs do not touch.

The last green CI run on master was in June; the runner images have moved since, so these two would have failed on any push. I am digging into both and will follow up.

🤖 Generated with Claude Code

[arekbr]

Verified on real hardware since opening this:

• Linux: full from-scratch build (fresh cmake configure + make) of master + this PR on Debian 13 / GCC 14 -- 0 errors, binary produced. This exactly reproduces the CI scenario that failed (the CI error was the missing GetWarpSpeed).
• macOS: the same combination (plus Fix macOS CI: build static SDL2 from source -- brew's sdl2 is now sdl2-compat without libSDL2.a #118) built from a fresh clone on a Mac Studio (arm64, Xcode 16.4) via ./build-macos.sh -- 0 errors, Retro Debugger.app produced. Without this PR the macOS build dies on the same two GetWarpSpeed call sites as Linux CI did, so this fix is needed for macOS as well, not just Linux.

[arekbr]

CI results across the three PRs confirm all three fixes -- each run now fails only on what its branch does not contain:

PR	branch contains	Linux	macOS	Windows
#117	GetWarpSpeed	✅ green	❌ old brew/sdl2 issue (needs #118)	❌ old _m_prefetch issue (needs #119)
#118	SDL2 staging	❌ GetWarpSpeed (needs #117)	❌ SDL2/Libtool step passes on Xcode 26.6, fails later on GetWarpSpeed	❌ _m_prefetch (needs #119)
#119	windows-2022 pin	❌ GetWarpSpeed (needs #117)	❌ brew/sdl2 (needs #118)	❌ _m_prefetch gone, fails later on GetWarpSpeed

The last open question from #118 is settled by its own run: on macos-26-arm64 / Xcode 26.6 the Libtool libMTEngineSDL.a step executes with -lSDL2 on the command line and succeeds -- the new libtool finds the staged archive via -L .../libs.

So: merge this one first, then #118 and #119 (any order) -- after all three, master should be green on all platforms.

[arekbr]

Final proof, measured rather than argued: I merged all three PRs (#117 + #118 + #119) into one test branch on my fork (test/all-three-ci-fixes) and ran the three workflows on GitHub's own runners:

platform	result
Linux	✅ success
macOS (macos-26-arm64, Xcode 26.6)	✅ success
Windows (windows-2022)	✅ success

Release artifacts got produced on all three. So after merging the three PRs, master goes green everywhere.