feat(khronos.vulkan-hpp): Vulkan-Hpp 1.4.357.0, the module Khronos already ships

[Sunrisepeak]

The index carried the Vulkan loader (compat.vulkan) and the C headers
(compat.vulkan-headers), and nothing that could answer import vulkan;.
This adds the package that can — and it authors no wrapper at all, because
there was never anything to author.

Khronos generates the C++ bindings in KhronosGroup/Vulkan-Hpp and releases
them, already generated, inside every Vulkan-Headers tag. The two module
interface units have been sitting in the tarball compat.vulkan-headers
already downloads — exposed through include/, compiled by nobody:

include/vulkan/vulkan.cppm         export module vulkan;
include/vulkan/vulkan_video.cppm   export module vulkan_video;

So this is the first package here to take shape C's first branch —
upstream already ships a .cppm, point straight at it. Every other module
package in this index synthesizes a wrapper, and every one of them can lose a
name silently when upstream moves. This one cannot: the export surface is
Khronos' own generated code.

Why the payload says Vulkan-Headers

Same tarball, URL and sha256 as compat.vulkan-headers, deliberately.
Pointing at the Vulkan-Hpp repository instead is worse in three measured ways:

• it has no vulkan-sdk-* tag at all (that URL 404s — its tags are v1.4.357,
  a different numbering from the SDK line the other Vulkan packages are keyed on);
• Vulkan-Headers is a git submodule there, and a GitHub archive never
  contains submodules;
• the second copy that would then be needed puts two vulkan/ include roots on
  the path, each holding a vulkan.hpp, with -I order deciding the winner.

One tarball makes the pair impossible to skew — and self-checking rather than
merely intended: the module unit opens with
VULKAN_HPP_STATIC_ASSERT( VK_HEADER_VERSION == 357 ), so a half-done version
bump fails to compile instead of shipping a mismatched pair.

Three decisions, none of them a preference

• khronos, not compat. In this index the namespace is the consumption
  contract: compat.* means #include, an owning namespace promises import.
  The module names stay upstream's vulkan / vulkan_video, never
  khronos.vulkan — the interface owner has already spoken, and renaming would
  make every Vulkan-Hpp tutorial wrong for mcpp users.
• import_std = true. Line 27 of vulkan.cppm is an unconditional
  export import std;; upstream gates its whole module target on
  23 IN_LIST CMAKE_CXX_COMPILER_IMPORT_STD for the same reason.
• The dependency is the loader, not just the headers. Vulkan-Hpp defaults to
  the static dispatcher (VULKAN_HPP_DISPATCH_LOADER_DYNAMIC is 0 without
  VK_NO_PROTOTYPES), so vk::enumerateInstanceVersion() compiles into a direct
  call to vkEnumerateInstanceVersion. Headers alone would give a package that
  compiles and then fails at every consumer's link.

No VK_USE_PLATFORM_*, exactly like upstream's Vulkan-HppModule target:
those defines are mutually exclusive per platform and cannot become a portable
feature, and the portable route needs none of them — GLFW and SDL2 hand back a
VkSurfaceKHR a consumer wraps as vk::SurfaceKHR{ raw }. Surface and
swapchain are in the module unconditionally; only the platform-specific
creation calls are not.

Tests

New workspace member tests/examples/vulkan-hpp-module:

• module.cpp has no #include anywhere in it. Asserts enumerator VALUES, the
  generated sType defaults, the constexpr format traits, the RAII layer's
  compile-time members, and two real loader calls through the static dispatcher
  — the link-time proof that the loader dependency reaches a consumer.
• video.cpp exists for the second unit alone: it says import vulkan;, so it
  can only be compiled after the first, out of a sources list that is just a
  list. It is the only thing that fails if that ordering stops working.

Verified

leg	result
linux · gcc 16.1.0	both units, both BMIs, 2 passed
linux · llvm 22.1.8	both units, both PCMs, binary runs

macOS and Windows take the same clang path as the llvm leg, and their runtime
half is already green through tests/examples/vulkan, which reaches the very
same loader entry points on all three legs.

⚠️ x86_64-windows-gnu (mingw) does not work and is documented in the
descriptor so nobody re-derives it — it is not a CI leg (the index's windows
toolchain is llvm/MSVC ABI). GCC-on-PE emits the module-attached function-local
static vk::errorCategory@vulkan()::instance into plain .bss in the consumer
object while the module object has it in a COMDAT, and the link dies with
multiple definition; separately, compat.vulkan's windows entry is an
MSVC-style vulkan-1.lib that mingw's ld does not find. Neither is fixable from
a descriptor.

compat.vulkan-headers gains the other half of that story: the tarball also
carries Vulkan-Hpp, this package builds it, and a version bump has to move both.