Task: Investigate and fix vcpkg-toolchain uninitialized-variable warnings

Linux CI builds under CMake 4.4.0 emit a second batch of CMake Warning (uninitialized) messages, distinct from the compiler-detection set already documented on the parent story. These originate from vcpkg/scripts/buildsystems/vcpkg.cmake rather than CMake's bundled CMakeDetermine*.cmake modules, but trip at the same project(OreStudio ...) call at CMakeLists.txt:51:

-- CMake Version: 4.4.0
CMake Warning (uninitialized) at vcpkg/scripts/buildsystems/vcpkg.cmake:60 (set):
  uninitialized variable 'VCPKG_MANIFEST_DIR'
Call Stack (most recent call first):
  .../CMakeDetermineSystem.cmake:152 (include)
  CMakeLists.txt:51 (project)

CMake Warning (uninitialized) at vcpkg/scripts/buildsystems/vcpkg.cmake:112 (set):
  uninitialized variable 'VCPKG_BOOTSTRAP_OPTIONS'
Call Stack (most recent call first):
  .../CMakeDetermineSystem.cmake:152 (include)
  CMakeLists.txt:51 (project)

CMake Warning (uninitialized) at vcpkg/scripts/buildsystems/vcpkg.cmake:114 (set):
  uninitialized variable 'VCPKG_OVERLAY_TRIPLETS'
Call Stack (most recent call first):
  .../CMakeDetermineSystem.cmake:152 (include)
  CMakeLists.txt:51 (project)

-- Running vcpkg install
CMake Warning (uninitialized) at vcpkg/scripts/buildsystems/vcpkg.cmake:541 (execute_process):
  uninitialized variable 'Z_VCPKG_FEATURE_FLAGS'
Call Stack (most recent call first):
  .../CMakeDetermineSystem.cmake:152 (include)
  CMakeLists.txt:51 (project)

Investigate whether these are cosmetic (vcpkg.cmake reading its own optional manifest/feature-flag variables before the toolchain sets them) or symptomatic of a real vcpkg configuration gap, and fix or suppress narrowly. Since both this and the parent story's warnings share the same trigger point and CMake version, resolve them together where the root cause overlaps.

• Root cause identified for the vcpkg.cmake uninitialized-variable warnings (VCPKG_MANIFEST_DIR, VCPKG_BOOTSTRAP_OPTIONS, VCPKG_OVERLAY_TRIPLETS, Z_VCPKG_FEATURE_FLAGS) under CMake 4.4.0.
• Confirmed whether they are purely cosmetic or indicate a real vcpkg configuration gap.
• Linux CI builds no longer emit these warnings (fixed at the source) or, if confirmed both upstream and harmless, explicitly and narrowly suppressed with a comment explaining why.

Diffed CI history around 2026-07-20 and found the trigger: a Dependabot PR (commit 18def3920) bumped lukka/get-cmake from 4.3.4 to 4.4.0 in the Linux CI workflow that day. Confirmed locally that our dev environment still runs CMake 4.3.4 and a fresh cmake --preset configure produces none of these warnings, isolating the cause to CMake 4.4.0 specifically.

Root cause: CMakePresets.json already sets warnings.uninitialized: true (intentionally, to catch real bugs in our own CMake code), but CMake < 4.4 didn't enforce that setting during the compiler/toolchain-detection phase triggered by project(). CMake 4.4.0 shipped a new unified diagnostic system (cmake_diagnostic()) that now enforces it end-to-end, newly surfacing vcpkg's bundled toolchain file's standard set(VAR "${VAR}" CACHE ... FORCE) idiom — valid CMake, harmless, but now flagged. Same root cause almost certainly also explains the parent story's compiler-detection warnings batch (CMAKE_SYSTEM_CUSTOM_CODE etc.), since both originate from the same project() call.

Since vcpkg's toolchain file is vendored (overwritten on the next vcpkg update) and we still want uninitialized-variable warnings for our own code, suppressed the diagnostic narrowly: bracketed only the project(OreStudio ...) call in CMakeLists.txt with cmake_diagnostic(PUSH) / cmake_diagnostic(SET CMD_UNINITIALIZED IGNORE) / cmake_diagnostic(POP), guarded behind CMAKE_VERSION VERSION_GREATER_EQUAL "4.4" so CMake < 4.4 (no cmake_diagnostic() command) and our current local dev CMake (4.3.4) are unaffected.

First attempt used cmake_diagnostic(SET uninitialized IGNORE) (the warnings.uninitialized preset key's own name); PR #1664's CI caught that this is the wrong category token — cmake_diagnostic() errors with "unrecognized diagnostic category 'uninitialized'", non-fatally, so configure continued but the suppression never took effect and the site CI job hard-failed downstream. Confirmed the correct token is CMD_UNINITIALIZED via the cmake-diagnostics(7) manual, then verified directly: downloaded the real CMake 4.4.0 binary (via pip download cmake==4.4.0, since it wasn't installable through normal package channels here) and ran cmake --preset against it — all five originally-reported warnings (the vcpkg.cmake batch and the parent story's compiler-detection batch) are gone and configure exits clean.

Verified against a real CMake 4.4.0 binary (obtained via pip download cmake==4.4.0 and extracted, since no system package was available locally) rather than by reasoning alone. Also surfaced, but did not fix (out of scope for this task): three more uninitialized-variable warnings CMake 4.4.0 newly reports elsewhere — CMakeLists.txt:274 (SPRINT), CMakeLists.txt:479 (DOGEN_VERSION), and projects/CMakeLists.txt:30 (flags) — plus two from CMake's own bundled CPack.cmake=/=InstallRequiredSystemLibraries.cmake modules. The first three are genuine gaps in our own CMake code and worth a follow-up capture; the CPack ones are the same vendored-file situation as this task but a different call site (include(CPack), not project()), so out of scope here too.

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Root cause identified: the 2026-07-20 Dependabot bump of lukka/get-cmake to 4.4.0 in Linux CI newly enforces our own long-standing warnings.uninitialized: true preset during project()'s compiler/toolchain-detection phase, which now flags vcpkg's vendored toolchain file's harmless cache-variable idiom. Fixed by narrowly suppressing the diagnostic only around the project(OreStudio ...) call in CMakeLists.txt via cmake_diagnostic(SET CMD_UNINITIALIZED IGNORE), guarded for CMake >= 4.4, so warnings for our own code are unaffected. First attempt used the wrong category token (uninitialized instead of CMD_UNINITIALIZED); PR #1664's CI caught it hard-failing the site job, corrected per the cmake-diagnostics(7) manual. Verified directly against a real CMake 4.4.0 binary (downloaded via pip, since not otherwise available locally): all five originally-reported warnings gone, configure exits clean.