[Blackhart]

Linked issues

No issues (Technical improvement)

Summarize your change.

This PR adds a GitHub Actions workflow that builds xSTUDIO on three platforms:

• Linux (Ubuntu 24.04 and Rocky 9, inside Docker)
• macOS (Apple Silicon)
• Windows (64-bit)

On each platform the job installs dependencies, then builds the project.
Unit tests are left out of CI for now (BUILD_TESTING=OFF): several tests still fail or time out (especially on Windows, and some on Linux). We can re-add a ctest step once those suites are cleaned up.
The PR also includes a few CMake and source fixes needed to compile with newer GCC on the Linux images and windows.

How Each OS Builds (and What Gets Cached)

Linux (Ubuntu 24.04 and Rocky Linux 9)

Linux builds run inside Docker containers based on Ubuntu 24.04 or Rocky Linux 9:

1. Toolchain image: Each distribution has its own base image, containing the compiler, CMake, Ninja, and Qt. These images are stored in GitHub Container Registry (GHCR) and are rebuilt only when the Dockerfile or pinned toolchain/Qt versions change. A content-hash tag ensures that unchanged configurations reuse the existing image.
2. Dependencies: Inside the container, vcpkg installs the third-party libraries. The resulting binary packages are cached as NuGet packages on GitHub Packages. Ubuntu and Rocky Linux use separate triplets to ensure ABI compatibility and prevent cache collisions.
3. xSTUDIO: The application is built inside the same container, using the previously installed dependencies. Compilation is accelerated by sccache, which caches compiler outputs to avoid rebuilding unchanged source files.

macOS (Apple Silicon)

The macOS build runs on the GitHub Actions runner (macos-latest).

1. Toolchain: Xcode/Clang, CMake, and Ninja are provided by the runner and Homebrew.
2. Qt: Qt is downloaded using aqt and stored in the GitHub Actions cache, allowing subsequent runs to skip the download when the Qt version remains unchanged.
3. Dependencies: Third-party libraries are installed using vcpkg. The resulting binary packages are cached as NuGet packages on GitHub Packages.
4. xSTUDIO: The application is built on the host, with sccache accelerating compilation by reusing cached compiler outputs

Windows (x64, Visual Studio 2022)

The Windows build runs on the GitHub Actions runner (windows-2022).

1. Toolchain: Visual Studio 2022 provides the MSVC compiler, while Ninja is used as the build system.
2. Qt: Qt is downloaded using aqt and stored in the GitHub Actions cache, allowing subsequent runs to skip the download when the Qt version remains unchanged.
3. Dependencies: Third-party libraries are installed using vcpkg. The resulting binary packages are cached as NuGet packages on GitHub Packages.
4. xSTUDIO: The application is built on the host, with sccache accelerating compilation by reusing cached compiler outputs.

What the Organization Needs to Know

1. GitHub Actions permissions: Enable GitHub Actions for the repository and ensure that the workflows are allowed to run the required actions and reusable workflows.
2. Package publishing permissions: Allow GitHub Actions to publish packages using GITHUB_TOKEN:
   1. Linux: Push Docker toolchain images to GHCR and publish NuGet packages to GitHub Packages.
   2. macOS and Windows: Publish NuGet packages to the same GitHub Packages feed.
3. Cost and storage: Standard GitHub-hosted runners use the organization's plan. No additional runner charges are expected as long as usage stays within the plan's allowances. The relevant storage allowances are:
   • Actions cache: 10 GB per repository by default, shared by Qt (macOS/Windows) and sccache.
   • GitHub Packages: Storage and bandwidth allowances depend on the organization's GitHub plan. GHCR container image storage and bandwidth are currently free.

Describe the reason for the change.

xSTUDIO targets Linux, macOS, and Windows. Compiling each pull request on those platforms before merge makes it easier to catch platform-specific build issues early, rather than discovering them later in the release cycle.

Describe what you have tested and on which operating system.

Verified via the new GitHub Actions workflow (build check, BUILD_TESTING=OFF):

• Linux: Ubuntu 24.04 and Rocky 9, built in Docker on ubuntu-latest
• macOS: Apple Silicon on macos-latest
• Windows: Windows Server 2022 + VS 2022 (windows-2022)

Add a list of changes, and note any that might need special attention during the review.

Alongside the CI work, this PR includes a few patches so the build can complete on each platform, plus a couple of runtime fixes.

Two of the fixes are Python-related (tested on Linux; review welcome on impact for macOS / Windows and whether this is the right approach):

• python/CMakeLists.txt (install layout): on non-Windows, pip install --prefix=… could put the pure-Python package under dist-packages (typical on Debian/Ubuntu) instead of lib/pythonX.Y/site-packages, where the rest of the build expects it. The step now copies the package into that site-packages location. Windows is unchanged and still uses pip install. Worth confirming this copy approach is acceptable on macOS too (same non-Windows branch).
• src/embedded_python/src/embedded_python.cpp (runtime, non-Windows): on Debian/Ubuntu, libpython often lives under /usr/lib/<triplet>/. Walking two parents from that path produced an invalid PYTHONHOME, and the embedded interpreter could fail at startup (module 'sys' has no attribute 'stdout'). The code now sets PYTHONHOME only when the library sits directly under lib / lib64, keeps the existing macOS app-bundle (Contents/Frameworks) path, and honours XSTUDIO_PYTHONHOME (as Windows already did). Windows uses a separate code path and is untouched aside from that shared idea of an override env var on Unix.

Unit tests are not run in CI yet (BUILD_TESTING=OFF). Some dependencies used do not match what the docs recommend (for example, some tests needs FFmpeg 8+), and some tests still fail or time out on Windows and/or Linux.

This PR also does not publish release binaries. Before CI ships installers or archives, we should agree how to handle FFmpeg: some builds/codecs are GPL, and that choice needs a clear project decision.