Sanitizer coverage gaps: no Vulkan driver on the sanitizer runner, server-count 1, and no TSan build option

# Problem Description

Three gaps mean whole classes of memory bugs cannot be caught by the sanitizer jobs, however long they run. They came to light while investigating #12706, a heap corruption that reproduces 4/4 locally and has apparently never appeared in a nightly sanitizer run.

**1. No Vulkan driver on the sanitizer runner, so no `(vk)` test is ever executed under ASan.**

`nightly-slang-sanitizer-test.yml` runs on a GitHub-hosted `ubuntu-22.04`, and `ci-slang-sanitizer.yml` installs no Vulkan driver — there is no reference to lavapipe, mesa, swiftshader or `VK_ICD` anywhere in it. The workflow states the consequence itself:

> GPU-requiring tests are skipped (no GPU available); this maximizes coverage of CPU, SPIRV-emit, and diagnostic tests under sanitizer.

The affected tests are not in any expected-failure list. There is simply no device, so they are ignored. The entire Vulkan *execution* path — as opposed to SPIR-V emission, which is covered — has never been under a sanitizer.

The CI container has the same gap: building ASan inside `ghcr.io/shader-slang/slang-linux-clang-ci:v1.0.1` and running a Vulkan test reports `Check vk,vulkan: Not Supported` and ignores every subtest. So installing a driver on the runner alone would not be enough for container-based jobs.

**2. `server-count: 1`, so the multi-server transport is never exercised under sanitizer.**

The nightly passes `server-count: 1`, and `ci-slang-sanitizer.yml` only adds `-use-test-server` when the count is greater than one. #12534 (test server intermittently returns malformed HTTP/JSON responses) is precisely about that transport, and it has never run under ASan.

**3. There is no ThreadSanitizer option, and ASan is weakest at exactly the bug class we are seeing.**

`SLANG_ENABLE_ASAN` is the only sanitizer the build system supports. TSan cannot be driven from outside CMake, because `cmake/CompilerFlags.cmake` applies sanitizer flags *per target* inside `slang_add_target` (the `SLANG_ENABLE_ASAN AND NOT ARG_SKIP_ASAN` branch), together with `-shared-libsan` and `--no-undefined` handling. Passing `-fsanitize=thread` through `CMAKE_CXX_FLAGS` and the linker-flag variables compiles everything instrumented but never links the runtime, so `--no-undefined` rejects the undefined `__tsan_*` symbols. It fails on `slang-rt`, then on `slang-glslang`.

This matters for #12706: that failure needs ~29 live threads, reproduces standalone 4/4, and disappears under both `gdb` and ASan. The symptom says race, and a race is what ASan is least able to see.

# Preferred Solution

1. Install `mesa-vulkan-drivers` (lavapipe) on the sanitizer runner **and** in the CI container, so `(vk)` tests execute under ASan. Lavapipe is a software rasterizer and needs no GPU.
2. Run at least one sanitizer configuration with `server-count > 1`, so the test-server transport is covered.
3. Add a `SLANG_ENABLE_TSAN` option mirroring the existing ASan branch in `cmake/CompilerFlags.cmake` — roughly twenty lines, including the `-shared-libsan` and `--no-undefined` accommodations that already exist for ASan.

# Alternative Solutions

The Vulkan coverage could go to a separate nightly job rather than the existing one, if adding a driver to the shared runner image is unattractive. That keeps the current job's runtime unchanged, at the cost of another job.

TSan could be left out on the grounds that ASan plus UBSan is the established configuration. The counter-argument is #12706: we currently have a reproducible memory bug that neither of them can see, and no supported way to point the matching tool at it.

# Additional context

For anyone building a sanitizer configuration in `ghcr.io/shader-slang/slang-linux-clang-ci:v1.0.1`, three things cost time and are documented nowhere:

- The build's own generators (`slang-embed`, `slang-fiddle`) are themselves instrumented and link the runtime dynamically, so `/usr/lib/llvm-18/lib/clang/18/lib/linux` must be on `LD_LIBRARY_PATH` or they fail to start with `libclang_rt.asan-x86_64.so: cannot open shared object file`.
- The image pairs clang-18 with binutils 2.38, and GNU ld cannot parse clang's default DWARF 5: `invalid or unhandled FORM value: 0x23`. `-gdwarf-4` avoids it; there is no `lld` in the image.
- Because the container has no Vulkan device, reproducing a `(vk)` failure means running the built binary on a host that has lavapipe, with the sanitizer runtime extracted from the image.

Split out of #12706, which covers the specific heap corruption. Related: #12534, #12032, #11215.

[]