docs: file #459 — five fragment shaders declare DemoteToHelperInvocation without the device feature

Found by the first validation-layer self-gate (S3 chunk 4 round 2). The
capability set is identical on the tip and the round-2 worktree, so it
predates chunk 4; the fix (enable the 1.3 feature or pin the compiler's
target to SPIR-V 1.5) gets its own commit.

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

docs/ISSUES.md

@@ -39,6 +39,39 @@ confirmed closed by the owner, 11 need a focused live gate, and 43 are safe to
 remain closed. See
 [`docs/research/2026-08-28-owner-closed-issue-validity-audit.md`](research/2026-08-28-owner-closed-issue-validity-audit.md).
 
+## #459 — Five fragment shaders declare SPIR-V `DemoteToHelperInvocation` without the device feature (validation error at every launch)
+
+**Status:** OPEN — found 2026-09-03 by the first Vulkan-validation-layer self-gate of Campaign OVERHAUL v2 (S3 chunk 4 fix round 2's gate; the layer was forced through the loader with `VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation`, since `ACDREAM_DEVTOOLS=1` only adds the debug-utils extension — `VulkanInterop.cs:182-183` creates the instance with `EnabledLayerCount = 0`).
+**Severity:** LOW today (every driver we run on accepts it), MEDIUM by the spec (undefined behavior: `VUID-VkShaderModuleCreateInfo-pCode-08740`)
+**Component:** `tools/ShaderCompiler` target environment / `VulkanGpuDevice` feature chain
+
+**Symptom:** with the Khronos validation layer active, `vkCreateShaderModule` reports twice per launch:
+`SPIR-V Capability DemoteToHelperInvocation was declared, but one of the following requirements is
+required (VkPhysicalDeviceVulkan13Features::shaderDemoteToHelperInvocation OR
+VkPhysicalDeviceShaderDemoteToHelperInvocationFeaturesEXT::shaderDemoteToHelperInvocation)`.
+`spirv-dis` over `src/AcDream.App/Rendering/Shaders/spv/*.spv` shows the capability in exactly five
+modules — `sky.frag`, `mesh_detail.frag`, `mesh_atmospheric.frag`, `directional_shadow_world_cutout.frag`,
+`directional_shadow_world_cutout_multiview.frag` — the five fragment shaders that use `discard`
+(glslang lowers `discard` to `OpDemoteToHelperInvocation` when the target SPIR-V is 1.6 / Vulkan 1.3).
+The set is IDENTICAL on the campaign tip and on the chunk-4 round-2 worktree, so the defect predates
+S3 chunk 4 (which touched only vertex shaders). `VulkanGpuDevice.cs:192` chains only the timeline-
+semaphore feature struct at device creation; no `VkPhysicalDeviceVulkan13Features` (or the EXT
+struct) is ever enabled, so the capability is declared without its feature.
+
+**Also seen (same run, performance warnings, 10× then muted):** `vkCreateGraphicsPipelines():
+pCreateInfos[0].pVertexInputState Vertex attribute at location 1 not consumed by vertex shader`
+for one module (`VkShaderModule 0xf400000000f4`) — a vertex-input state that declares an attribute
+its shader never reads; harmless, identify the pipeline when fixing this issue.
+
+**Fix direction (own commit, not a chunk-4 item):** EITHER enable `shaderDemoteToHelperInvocation`
+through a chained `VkPhysicalDeviceVulkan13Features` when the device is 1.3-capable (the feature is
+core in 1.3 and the seal/punch/sky paths already assume a 1.3 device), OR pin the managed compiler's
+target to Vulkan 1.2 / SPIR-V 1.5 so `discard` lowers to `OpKill` again and re-pin the five hashes in
+`VulkanShaderManifestTests`. Add the validation-layer run to the self-gate kit as an explicit switch
+so this class is caught on every gate, not only when the lead remembers the env vars. Logs:
+`.claude/worktrees/s3-chunk4-impl/logs/vk-validation-chunk4-r2.log` (round 2) and
+`logs/vk-validation-tip-baseline.log` (tip).
+
 ## #458 — Walk admits land block `a9c9` at holtburg-doorway-still that retail does not draw
 
 **Status:** RESOLVED 2026-09-03 — a PRECISION BOUNDARY, not a walk defect (register row AD-118; the KnownFailure row is kept on purpose — see the resolution below). Found 2026-09-03 by the S3 chunk 1 eight-kind transcript conformance (the gate's first real walk catch).