Transition LightweightVK to Vulkan 1.4

1. Goal

Make Vulkan 1.4 the minimum target for LightweightVK and bring the enabled feature set in line with the Khronos Roadmap 2022 / 2024 profiles.

The transition is unconditional. There are no opt-in flags, runtime version queries, or conformance-check helpers — every item below is a small, mechanical code change that either enables a feature, switches an entry point to its core form, or deletes legacy plumbing.

This is a tracking issue. Each [ ] item should become its own small, self-contained PR (or be batched with closely-related items) so the work can land incrementally.

2. Vulkan 1.4 transition tasks

2.1 Make Vulkan 1.4 the minimum API version

• ❌ Delete the VulkanVersion enum (lvk/LVK.h:1280-1283) and the ContextConfig::vulkanVersion field (lvk/LVK.h:1286).
• ❌ Hard-code VkApplicationInfo::apiVersion = VK_API_VERSION_1_4 (lvk/vulkan/VulkanClasses.cpp:6687-6691).
• ✅ Delete every #if defined(VK_API_VERSION_1_4) guard. The bundled Vulkan-Headers are already at 1.4.341, so the guarded blocks are the only branch that ever compiles. Affected sites: VulkanClasses.h:723-725, 739-745, VulkanClasses.cpp:6687-6691, 6998-7005, 7143-7157. (09b6363)
• ❌ Delete the legacy if (config_.vulkanVersion < VulkanVersion_1_4) extension-enable block at VulkanClasses.cpp:7257-7264. The four promoted extensions (VK_KHR_push_descriptor, VK_KHR_maintenance5, VK_KHR_dynamic_rendering_local_read, VK_KHR_index_type_uint8) and their feature structs collapse into the 1.4 features struct.
• ✅ Drop the LVK_ASSERT_MSG(... "Only Vulkan 1.3 is supported on this platform") at VulkanClasses.cpp:7004 along with the surrounding #else branch. (09b6363)
• ✅ Update CI matrix to install Vulkan SDK 1.4.341+ on Linux/Windows (already the case on macOS via bootstrap-deps.json). (c57a095)

2.2 API surface clean-up (entry-point promotion)

Vulkan 1.4 promoted several entry points that LVK still calls via the KHR alias. These calls work on 1.4 (the alias resolves to the core function via volk), but they leave a misleading paper trail:

• ❌ vkCmdBindIndexBuffer2KHR → vkCmdBindIndexBuffer2 (lvk/vulkan/VulkanClasses.cpp:2753, has an explicit // TODO: remove KHR note).
• ❌ vkCmdPushDescriptorSetKHR → vkCmdPushDescriptorSet (lvk/vulkan/VulkanClasses.cpp:2705).
• ❌ Audit remaining *MaintenanceN_KHR, *PushDescriptor*KHR, *DynamicRenderingLocalRead*KHR symbols and drop the suffix.

3. Roadmap profile alignment

The two Roadmap profiles (Khronos Vulkan-Profiles) are used here purely as a menu of features to enable, grouped by year. We do not query for profile support, do not gate behavior on it, and do not advertise conformance — we just walk the lists and turn features on one PR at a time.

Each profile is tracked in its own checklist file:

• ✅ Roadmap 2022 — VP_KHR_roadmap_2022, built on Vulkan 1.3, subsumed by our 1.4 floor.
• ✅ Roadmap 2024 — VP_KHR_roadmap_2024, inherits Roadmap 2022; mostly absorbed into Vulkan 1.4 core. LVK 1.4.3

4. Vulkan 1.4 "Additional Functionality" not in any Roadmap profile

The Vulkan 1.4 proposal lists these as required by 1.4 but does not classify them under Roadmap 2022 or 2024.

VkPhysicalDeviceFeatures (Vulkan 1.0 features)

• ✅ largePoints (32a7876)

VkPhysicalDeviceVulkan11Features

• ✅ variablePointers (5f613a1)
• ✅ variablePointersStorageBuffer (2d178c7)

VkPhysicalDeviceVulkan14Features

• ❌ shaderSubgroupRotateClustered
• ❌ bresenhamLines
• ✅ indexTypeUint8 (3a15a51)
• ✅ dynamicRenderingLocalRead
• ✅ maintenance5
• ❌ maintenance6
• ✅ pushDescriptor (366356a)