Build the Linux kit against pinned Vulkan headers and without #embed, and try the compiler before the long steps.

A player's AppImage build of 0.7.1 stopped in its compile step after eight minutes of RomFS work: four
files did not compile, because the kit builds with the system's compiler and headers and theirs were
older than the runtime needs. vk_pipeline.c and vk_device.c name VK_KHR_pipeline_binary,
VK_KHR_dynamic_rendering_local_read and VK_KHR_shader_maximal_reconvergence, which their Vulkan headers
did not declare, and ui/menu.cpp takes its font in with #embed, which clang has from version 19.

- Vulkan headers: tools/vulkan_pin.py holds the release the other builds use (1.4.363, the archive and
  hash tools/make_release_linux.py already pinned, which now reads them from there). The AppImage carries
  its C headers in toolchain/vulkan-headers and builds against them whatever the system has; a kit or a
  source checkout uses the system's when they are at least that release and fetches the pinned ones
  otherwise (build_game.py vulkan_include). Their folder goes first on the include path of the runtime's
  sources only, so the lifted code's objects keep their keys, and a runtime object compiled before
  against the system's headers is taken over instead of compiled again. AppRun no longer asks for the
  system's Vulkan headers.
- #embed: tools/build_shaders.py also writes the font's bytes as runtime/ui/roboto_ttf.h (ignored by git,
  carried by a kit), and menu.cpp includes that where the compiler has no __has_embed. With #embed
  nothing changes.
- Before its long steps a Linux build that will compile now checks every runtime source that needs no
  header of the install with the compile step's own command (clang -fsyntax-only) and links an empty
  program against the game's libraries (make_game.py preflight): an old compiler, an old header or a
  missing development package stops it in the first seconds with the compiler's own errors. A failed
  compile names every file that failed, not only the three whose errors it prints.

Checked on Windows: tests/launcher_test.py passes with four new tests (117); the header of bytes and
#embed give the same 162,588 bytes, and both branches of menu.cpp compile; the early check passes on the
Windows file set with clang 23 and stops on files made to fail; the 34 local headers of release 363 are
the upstream tag's files by git blob id. Not run: anything on Linux, the pinned archive's download, a
compiler older than 23.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs/README-BuildKit.md

@@ -78,6 +78,17 @@ RADV). It takes clang, clang++ and lld from `PATH` and links against the system'
    (GPL-2.0): `pip install --user zbic`, or in a virtual environment with the packages above.
    Vulkan Memory Allocator is one header: the system's (AUR `vulkan-memory-allocator`), else the build fetches the
    pinned 3.4.0 into `toolchain/vma/` and checks its hash.
+   The Vulkan headers must be release 363 (1.4.363) or newer: the runtime names extensions that older headers do not
+   declare (`VK_KHR_pipeline_binary` among them), and distributions with long support package older ones. The
+   AppImage carries the pinned headers (`toolchain/vulkan-headers/`, `tools/vulkan_pin.py`) and builds against them
+   whatever the system has; a build from a kit or a source checkout uses the system's when they are new enough and
+   otherwise fetches the pinned ones there once and checks their hash. The loader's library still comes from the
+   system (`vulkan-icd-loader`, `libvulkan-dev`, `vulkan-loader-devel`).
+   The compiler is the system's too. The releases are built with clang 23; an older one works as far as it compiles
+   the runtime (one without `#embed`, before clang 19, takes the menu's font from a header the kit carries). Before
+   its long steps the build checks every runtime source with that compiler and links against the libraries, so a
+   compiler, a header or a library it cannot use stops it in the first seconds, with the compiler's own words, and
+   not after the RomFS image.
 
 2. The shader translator: a kit with `bin/nx2navi_xlate` has it; from a source checkout, build it once with
    `python tools/build_xlate.py` (needs the .NET 10 SDK). The build copies it beside the game. A kit also carries the
@@ -132,8 +143,9 @@ switches at once, with a *DLSS multiplier* of 2x to 6x (above 2x on RTX 50 cards
 frames needed to reach the display's refresh rate (`framegen = dlss` and `fg_mult` in `nx2navi.ini`). The log says
 `ngxfg: DLSS Frame Generation available` when NGX found the library.
 
-`tools/make_appimage.py` packs this kit into one `NX2navi-Linux-<version>-x86_64.AppImage` with its own Python, for
-players without a source checkout: it checks for the packages above, installs zbic with pip on its first run, picks
+`tools/make_appimage.py` packs this kit into one `NX2navi-Linux-<version>-x86_64.AppImage` with its own Python and the
+pinned Vulkan headers, for players without a source checkout: it checks for the packages above (their Vulkan headers
+are not needed), installs zbic with pip on its first run, picks
 `--jobs` from the memory, builds into `~/Games/Ocarina` (or the folder given after the dump) and writes `play.sh`
 beside the game.