Investigate imported-target workaround in downstream consumers; fix or simplify

[joshkamm]

ZEST's CMakeLists (CMakeLists.txt:45-118) contains ~74 lines of diagnostics and find_library fallback for SlaterGPU::io and SlaterGPU::cintw, with comments suggesting these targets sometimes appear without IMPORTED_LOCATION. XCtera's CMakeLists (CMakeLists.txt:38-49) has a slimmer version of the same fallback.

SlaterGPU's actual install/export setup (src/CMakeLists.txt:13-30) does correctly install SlaterGPU, io, and cintw to EXPORT SlaterGPUTargets. So the fallback may be vestigial defensive code from a past defect.

Goal

Determine the truth of the matter and act on it.

Investigation steps

1. Build ZEST against a clean SlaterGPU install. Inspect the actual values of IMPORTED_LOCATION, IMPORTED_LOCATION_RELEASE, and IMPORTED_IMPLIB on SlaterGPU::io and SlaterGPU::cintw — the message(STATUS ...) calls at ZEST/CMakeLists.txt:53-92 already print these — read them.
2. If properties are populated correctly: open follow-up PRs in ZEST and XCtera to delete the fallback (this issue closes as "no source fix needed; consumers will be simplified separately").
3. If properties are missing: identify the install/export step that's incomplete (likely something about SHARED libs missing the LIBRARY DESTINATION interaction, or build-type-specific IMPORTED_LOCATION_<CONFIG> not being set). Fix in SlaterGPU.

Legacy workflow impact

Low. Paul's Makefile doesn't use find_package(SlaterGPU). Manual CMake builds (no pixi) benefit from any source fix.

Acceptance

• Either: SlaterGPU's exported imported targets carry IMPORTED_LOCATION correctly, and ZEST/XCtera CMakeLists drop the fallback in their respective follow-up PRs.
• Or: confirmed working as-is and the workaround is documented as removable; follow-up cleanup PRs are filed against ZEST and XCtera.

Context

Part of a broader dependency-infrastructure effort tracked in ZimmermanGroup/XCtera (umbrella tracking issue will be linked once filed).