optimize binary BitSet operations for rvalue-ref args (#6053)

ci(test-only): fix smoke-test steps -- use 'call' for nested .bat

Without 'call', invoking thirdparty\install.bat from another cmd script
transfers control permanently and the parent script's if/echo never run.
The previous run (74366682868) showed install.bat correctly exiting 1
("Error: --extra-requirements requires a file path argument.") but the
step still failed because the temp script just inherited that exit code.

Add explicit 'exit /b 0' at the end of each step so the success path
returns clean.

ci(prepare-images): keep matrix cell name as "(<distro>, <arch>)"

Dynamic-include cells get auto-named from every key in the entry,
so the previous shape produced
  linux-image-build-upload (ubuntu22, arm64, -arm64, ubuntu-24.04-arm)
duplicating arm64 and leaking runner/image-suffix details.

Drop image-suffix and os from the matrix entries and derive both
from matrix.arch inline (runs-on + image env). Cell name is now
just "(<distro>, <arch>)", matching the static-matrix baseline.

ci(vcpkg): skip Release build for x64-windows-meshlib-iterator-debug …

…triplet

The x64-windows-meshlib-iterator-debug triplet is only consumed by the
Debug-IteratorDebug matrix cell in windows-*-config.json, which links
exclusively against the Debug variant. Building the Release variant in
prepare-images.yml's windows-vcpkg-build-upload job (and writing it to
the per-triplet S3 cache at s3://vcpkg-export/<tag>/<triplet>/) is wasted
work.

Set VCPKG_BUILD_TYPE=debug in the triplet so vcpkg only produces Debug
artifacts. The Release variant of x64-windows-meshlib (used by Release
consumers) is unaffected since cache paths are partitioned by triplet.

Also drop the redundant "-T v142" added via VCPKG_CMAKE_CONFIGURE_OPTIONS;
the platform toolset is already pinned by VCPKG_PLATFORM_TOOLSET above.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ci(windows): cache MSYS2 mrbind tree via actions/cache

The install-msys2-mrbind composite action previously fetched the
~1 GB msys64_meshlib_mrbind.zip from S3 on every Windows job. The
S3 object has been seen returning 404 in CI runs even with five
exponential-backoff retries, hard-failing the entire pipeline.

Wrap the fetch in actions/cache@v4 so the extracted tree at
C:\msys64_meshlib_mrbind is restored from the GitHub Actions cache
on subsequent runs. The S3 download path remains as the cold-cache
fallback, preserving the existing retry logic.

Cache key embeds a manual revision suffix (v1) plus the hash of
action.yml, so changes to the action invalidate the cache
naturally. If the upstream zip is ever re-uploaded under the same
URL, bump the v1 suffix to force a refresh.

thirdparty(vcpkg): drop zlib-ng static-linkage pin on Linux triplets

The auditwheel/zlib-ng incompatibility (pypa/auditwheel#613) is already
handled on this branch by scripts/wheel/strip_zlib_ng_symbol_versions.py,
which rewrites every consumer .so so its .gnu.version_r no longer
carries the libz-ng entry before auditwheel runs. With that in place
the static-linkage workaround is redundant -- restore the default
VCPKG_LIBRARY_LINKAGE=dynamic so libz-ng on Linux-vcpkg matches every
other platform and libMRMesh.so stays a thin shared library.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ci(vcpkg): overlay zlib-ng with upstream 2026.03.18 port content

vcpkg 2024.10.21's stock zlib-ng port (zlib-ng 2.1.5#1) has a bug
that breaks our `zlib` empty-shim → zlib-ng-compat path on the vs2019
leg: the portfile's vcpkg_cmake_configure block forgets to pass
-DZLIB_COMPAT=${ZLIB_COMPAT} (and the matching default-OFF init) to
the actual cmake build, so the build always runs in NATIVE mode
(producing zlib-ng.pc, libz-ng.dll), regardless of triplet. But the
post-install fixup later in the same portfile *does* read ZLIB_COMPAT
and goes looking for zlib.pc, which the build never produced:

    CMake Error at scripts/cmake/vcpkg_replace_string.cmake:12 (file):
      file failed to open for reading (No such file or directory):
        .../zlib-ng_x64-windows-meshlib-iterator-debug/lib/pkgconfig/zlib.pc
    Call Stack:
      ports/zlib-ng/portfile.cmake:41 (vcpkg_replace_string)

vcpkg 2026.03.18 fixes this (zlib-ng 2.3.3, with the missing
-DZLIB_COMPAT line and default init), so vs2022 (which uses 2026.03.18)
already passes. vs2019 stays pinned to 2024.10.21 to keep its v142
toolchain coverage; pinning vcpkg there cannot be changed without
breaking matrix coverage.

Solution: overlay our own copy of vcpkg's zlib-ng port that mirrors
the 2026.03.18 content (zlib-ng 2.3.3 + the proper ZLIB_COMPAT
threading). Vcpkg's --overlay-ports makes our overlay take precedence
regardless of which base vcpkg version is in use, so vs2019 and vs2022
now both build zlib-ng 2.3.3 with consistent ZLIB_COMPAT plumbing.

A side benefit: vs2019 and vs2022 now produce the same zlib-ng
binary version, eliminating the zlib-ng-2.1.5 vs zlib-ng-2.3.3 drift
that was previously causing many.zip size differences at deflate
levels 1-3 between the two legs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Merge remote-tracking branch 'origin/test/compress-times' into feat/z…

…lib-compress-stream-libdeflate

remove unnecessary information from stl and obj headers (#5841)

remove unnecessary information from stl and obj headers (#5841)