[SPIR-V] DXC is ignoring include handler when searching for the source to embed into SPIRV.

Description
When compiling a shader using dxcompiler.dll with a custom include handler into SPIRV with -Zi -fspv-debug=vulkan-with-source -Qembed_debug, DXC requests includes from the custom handler and uses its output to compile the shader. However, when embedding source code into SPIRV, DXC ignores the custom include handler output, does not request anything from it, and instead tries to read the source directly from the system only using include directories passed with -I.

If a file cannot be found by prepending either the execution directory or one of the additional include directories to the include string, the search will fail. If such a search fails, compilation still succeeds, but the included source is not present in the resulting SPIRV. If the search succeeds, the resulting SPIRV can contain source code that is not the source from which the SPIRV was actually compiled because DXC may find an incorrect source file.

I confirmed this both by tampering with sources inside the include handler (if the path to the source was provided through the -I argument, the SPIRV contains the original source rather than the tampered version) and by using Process Monitor, which shows file requests made directly by DXC.

This may be related to #4805, but I did not notice crashes or cases where DXC ignores the include handler completely. In my case, the include handler is used for compilation, and the only case when it is ignored is when embedding source code.

Steps to Reproduce

1. Compile any shader that uses includes with dxcompiler.dll using a custom include handler that can find sources for includes, but make sure these sources cannot be found without the include handler. Use the arguments -Zi -fspv-debug=vulkan-with-source -Qembed_debug. The compilation succeeds, but the resulting SPIRV contains only the "root" source that was passed for compilation and does not contain the included sources.

2. Compile any shader that uses includes with dxcompiler.dll using a custom include handler that can find the included sources and tamper with them (for example, by replacing a word), and pass absolute paths to the source directories using -I "path", so that the included sources can also be found without the custom include handler. Use the arguments -Zi -fspv-debug=vulkan-with-source -Qembed_debug. The compilation succeeds, and the resulting SPIRV contains the included sources, but they are not the tampered versions returned by the custom include handler.

Actual Behavior
DXC should either use the source returned by the custom include handler for both compilation and embedding or, at least, request the source a second time through the same custom include handler when embedding. It should definitely not browse the filesystem by itself, as this defeats the purpose of custom include handlers.

Environment

• DXC version dxcompiler.dll: 1.9(5402-0d3ee6b5)(1.9.0.5402) - 1.9.0.5402 (0d3ee6b55-dirty)
• Host Operating System Windows 11 Pro 23H2

Start by reproducing the issue with dxcompiler.dll, a custom include handler, and -Zi -fspv-debug=vulkan-with-source -Qembed_debug. Trace the SPIR-V source-embedding path and compare its source requests with the handler output used during compilation. Done means embedded sources match the handler-provided sources and DXC does not independently search the filesystem.