Clarify SPV_EXT vs SPV_KHR opacity_micromap behavior equivalence

[dgkoch]

Spell out in the SPV_KHR_opacity_micromap Issues resolution that:

• Declaring either OpExtension string without OpacityMicromapIdKHR produces the same shader behavior.
• SPV_EXT_opacity_micromap alone does not imply OMMs are always present.
• Whether OMM data is consumed during traversal is gated by which Vulkan extension is enabled:
  • VK_EXT_opacity_micromap: OMMs always consumed when present.
  • VK_KHR_opacity_micromap: OMMs consumed only when the shader declares OpacityMicromapIdKHR.

Bumps Last Modified Date to 2026-06-12 and revision to 4.

Resolves the ambiguity raised in vulkan/vulkan#4842.

[dgkoch]

Iterated per RT TSG 2026-06-25 feedback (600fec0d). Three things changed:

1. Reference the Vulkan opacity_micromap micromap feature being enabled at the API level, rather than "declaring the extension string." This matches Vulkan's actual gating model (enabling the extension isn't enough — the feature has to be enabled too), and it disambiguates the KHR case where both an extension and a feature are in play.

2. Restructured the resolution as a bulleted list for readability.

3. Explicit undefined for the mismatch case. If a shader traces an acceleration structure that contains opacity micromap data with the VK_KHR_opacity_micromap micromap feature enabled but without declaring OpacityMicromapIdKHR, the traversal result is undefined — this is NOT equivalent to a skip-OMM ray flag. Applications must opt in via the execution mode when they intend to use opacity micromap data.

@HansKristian-Work @dnovillo — please take another look.

[dnovillo]

LGTM.

[dgkoch]

Propagating the same two corrections that landed on the parallel Vulkan-side MR (!8409) after Matt Netsch's review there:

• VK_EXT_opacity_micromap is extension-gated, not feature-gated. The EXT capability entry in vk.xml has been <enable extension="VK_EXT_opacity_micromap"/> since day one (2022), and VUID-*-micromap-11636 gates on the extension being enabled. Only the KHR path is feature-gated. The EXT sub-bullet and the introductory line have been updated to reflect that (822b0b2).
• The KHR opt-in requires the OpacityMicromapIdKHR operand to equal VK_TRUE. Per VU 11636, declaring the execution mode with the operand set to VK_FALSE doesn't count as opting in. Reflected in the KHR sub-bullet and in the "traversal result is undefined" bullet (822b0b2).

The fourth bullet (added earlier for Wooyoung) is unchanged — it's about whether the module can declare the execution mode at all, which the operand value doesn't affect.