feat: provide pre-built static and shared libraries in release assets

[s2x]

Description

Currently, GitHub releases only contain source code archives. While Python wheels are distributed via PyPI, there are no pre-built artifacts for C/C++ consumers. This makes it unnecessarily difficult to integrate zvec into projects in other languages that need to link against the native library.

Motivation

I'm working on a PHP extension for zvec that wraps the C API. Building zvec and all its dependencies from source in CI is extremely complex and error-prone — especially across different platforms and toolchains. Having pre-built artifacts available would dramatically accelerate development of language bindings (PHP, Ruby, Rust, Zig, etc.).

Request

Please add pre-built both static (.a) and shared (.so/.dylib) libraries to GitHub release assets for the following platforms:

Platform	Arch	Format
Ubuntu 20.04+ / Debian 11+	x86_64	.tar.gz
Ubuntu 22.04+ / Debian 12+	x86_64	.tar.gz
Ubuntu 24.04+	x86_64	.tar.gz
Fedora 39+	x86_64	.tar.gz
macOS 13+ (Intel)	x86_64	.tar.gz
macOS 14+ (Apple Silicon)	arm64	.tar.gz
(optional) Linux	aarch64	.tar.gz

Each archive should ideally contain:

• libzvec_db.a / libzvec_core.a (static)
• libzvec_db.so / libzvec_core.so or .dylib (shared)
• C/C++ headers
• A lib/cmake/ or equivalent for find_package(zvec)

Benefits

• Language bindings: dramatically simpler CI for PHP, Ruby, Rust, Zig, etc.
• End users: easier to vendor zvec without CMake or a full C++ toolchain
• Consumption in non-CMake projects: Makefile, Zig build, or manual link workflows
• Cross-compilation: fewer bootstrap cycles for non-primary targets

Related

• Issue Segfault at process exit when zvec is statically linked (glog/protobuf destructor ordering) #206 discusses challenges with static linking — pre-built artifacts would make testing and distributing static builds simpler.
• Python wheels already ship platform-specific binaries; extending this to raw C/C++ artifacts would cover the remaining use cases.

Notes

• The Python wheel build infrastructure (.github/workflows/build_wheel.yml, cibuildwheel) could potentially be reused or adapted for producing these artifacts.
• A matrix similar to the existing wheel build matrix would suffice.