Thanks @ten9876 — this is a clean, well-scoped vendoring change. Minimal blast radius outside third_party/ (only 4 files, +31/-25), and the constitution-alignment rationale is documented both in the PR body and inline at CMakeLists.txt:43-50 and THIRD_PARTY_LICENSES entry #13. Verified on main that ZLIB::ZLIB had only one consumer (AetherSDR itself), so dropping find_package(ZLIB REQUIRED) doesn't orphan any other target — Qt's transitive system-zlib use is correctly called out as out-of-scope.

A few small things, none blocking:

1. Trim list slightly inconsistent with PR body. The description lists the directories that were trimmed, but the vendored tree still contains test/ (example.c, infcover.c, minigzip.c), zlib.3, zlib.3.pdf, make_vms.com, and Makefile.bor. With ZLIB_BUILD_EXAMPLES OFF + EXCLUDE_FROM_ALL they're inert, but if the goal was a lean vendor tree (and to keep the diff easier to re-vendor on the next bump), test/, make_vms.com, Makefile.bor, and the manpage PDF are safe to drop too. Optional — purely a hygiene thing.

2. Worth confirming MSVC CRT flag consistency. zlib 1.3.1's CMakeLists.txt doesn't override /MD vs /MT, so it inherits whatever CMake picks for the project, which should match AetherSDR. The fact that you've verified the Windows installer artifact builds cleanly is the real test, but if Windows CI hasn't been re-run since the rebase, that's the one box left to tick.

3. zlibstatic include propagation. Upstream zlib 1.3.1 sets target_include_directories(zlibstatic PUBLIC ...) on both source and binary dirs (the latter for the generated zconf.h), so AetherSDR TUs that #include <zlib.h> should resolve via the target's INTERFACE properties — no extra target_include_directories needed in our top-level CMakeLists.txt. You've already verified the Linux/macOS build, so this is just noting the mechanism for future readers.

4. Optional follow-up: consider adding a THIRD_PARTY_VERSIONS (or extending the THIRD_PARTY_LICENSES entry) with a one-line "to bump: download v$X tarball, verify sha256, drop into third_party/zlib/, re-trim per this list." Will save the next person 30 minutes when zlib 1.3.2 lands.

LGTM as a Principle III correctness fix. Single source of truth across all three platforms is the right call, and avoiding the zlib1.dll copy in the Windows installer is a nice ergonomics win.

Thanks @ten9876 — clean execution of the constitution's bundled-deps preference, and it nicely mirrors the libmosquitto pattern (#699).

The integration touchpoints all look right to me:

• add_subdirectory(third_party/zlib EXCLUDE_FROM_ALL) + target_link_libraries(... zlibstatic) is the correct shape — upstream zlib 1.3.1's CMakeLists sets target_include_directories(zlibstatic PUBLIC ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR}) (lines 153–155), so <zlib.h> propagates through the link without needing a separate target_include_directories on AetherSDR. Good — I had to double-check that since find_package(ZLIB) users sometimes get burned bundling zlib via add_subdirectory.
• ZLIB_BUILD_EXAMPLES OFF + SKIP_INSTALL_ALL ON keep the example targets and the install(TARGETS zlib zlibstatic …) block from leaking into our install tree. ✓
• Removing the vcpkg step from both ci.yml and windows-installer.yml, plus the zlib*.dll copy from windows-installer.yml, are consistent with the static-link decision. ✓
• THIRD_PARTY_LICENSES entry #13 has copyright, license name, source URL, and version — matches the format of the existing entries. ✓
• Trim list (amiga/contrib/doc/examples/msdos/nintendods/old/os400/qnx/watcom) plus the noted exception for win32/ (zlib's CMakeLists unconditionally references win32/zlib1.rc for the shared target) is correct. ✓

A few small notes, none blocking:

1. CMake deprecation warning at configure time. Upstream zlib's cmake_minimum_required(VERSION 2.4.4...3.15.0) will produce a deprecation warning under CMake ≥ 3.27 because the floor is below 3.5. Purely cosmetic, can't fix without forking the vendored tree — worth knowing if reviewers see warning noise in CI logs.
2. Qt's transitive system zlib remains. Your verification note already calls this out, but flagging it for future readers: Qt6 still pulls in the system libz dynamically (via QtCore on Linux), so on Linux/macOS the process has both our statically-linked zlib 1.3.1 and the system libz mapped. That's normal and the symbols don't conflict (static lib's symbols are internal-only), but it's a "two zlib's in the process" thing worth being aware of if anyone ever debugs strange compression-related behavior.
3. Self-contained Windows installer is a real win — agree the artifact no longer needing zlib1.dll shipped separately is the cleanest outcome here.

LGTM as a comment review. Nice cleanup.