Bump duckdb / libduckdb-sys crate to the DuckDB 1.5.2 release (1.10502.0)

[rustyconover]

Hi! 👋

The duckdb and libduckdb-sys crate dependencies in this extension's Cargo.toml are pinned with = to 1.10501.0 — which corresponds to DuckDB 1.5.1. Since the pin is exact (=), cargo update can't move it forward, and the built extension carries the 1.5.1 ABI / version header even when built against a newer DuckDB.

DuckDB has since released 1.5.2 (crate: 1.10502.0). Patch releases within 1.5.x are ABI-compatible, so the bump is usually a no-op as far as your code goes.

Suggested change

 [dependencies]
-duckdb = { version = "=1.10501.0", features = [...] }
-libduckdb-sys = { version = "=1.10501.0", features = [...] }
+duckdb = { version = "=1.10502.0", features = [...] }
+libduckdb-sys = { version = "=1.10502.0", features = [...] }

If you'd rather not pin to a specific patch level at all, a tilde or caret constraint would let future 1.5.x releases roll in automatically:

duckdb = { version = "~1.10502", features = [...] }
libduckdb-sys = { version = "~1.10502", features = [...] }

Why this matters

For users on DuckDB 1.5.2 (and for Haybarn, a derived distribution we maintain that tracks v1.5.2), the version header embedded in the built .duckdb_extension doesn't match the engine's reported version, which can surface as an INSTALL / LOAD-time mismatch. Bumping the pin produces a binary that loads cleanly against any 1.5.2 engine.

Context

I'm one of the maintainers of haybarn-community-extensions, where we rebuild the DuckDB community-extensions catalog against the Haybarn engine. We surveyed Cargo.tomls across cargo-using extensions and this one stood out as easy to bring current.

Happy to send a PR if it'd help — just let me know! Either way, thanks for maintaining this extension. 🙏