Fix system zstd propagation to SPZ

[eclipse0922]

Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Motivation and Context

When USE_SYSTEM_ZSTD=ON, Open3D resolves zstd during the top-level CMake configure, but the nested SPZ ExternalProject starts a separate configure without the resolved package location.

SPZ then fails to find the system zstd package, downloads its own copy, and disables installation of the SPZ target because the fetched dependency is not exportable. Open3D subsequently cannot compile against the expected installed SPZ headers, such as spz/load-spz.h.

This change passes the top-level zstd_DIR directly to the nested SPZ configure. The bundled-zstd path remains unchanged.

Checklist:

• I have run python util/check_style.py --apply to apply Open3D code style to my code.
• This PR changes Open3D behavior or adds new functionality.
  • Both C++ (Doxygen) and Python (Sphinx / Google style) documentation is updated accordingly. No public API changes are introduced; CHANGELOG.md documents the build fix.
  • I have added or updated C++ and / or Python unit tests OR included test results (e.g. screenshots or numbers) here.
• I will follow up and update the code if CI fails.
• For fork PRs, I have selected Allow edits from maintainers.

Description

The generated ext_spz configure command now contains:

-Dzstd_DIR:PATH=<resolved-system-zstd-dir>

Validation performed on Linux with GCC 11.5 and CMake 3.28:

• Reproduced the missing -Dzstd_DIR argument before the change.
• Verified system mode passes the resolved vcpkg zstd package directory.
• Clean-built and installed ext_spz against vcpkg zstd and zlib.
• Verified include/spz/load-spz.h and lib/libspz.a are installed.
• Verified bundled mode still passes ZSTD_CONFIG_DIR.
• Ran python util/check_style.py --apply with the pinned style dependencies; all files passed.