feat: implement DuckDB filesystem integration for Vortex file handling

[iceboundrock]

• This PR addresses DuckDB extension to use DuckDB FileSystem #5767
• This PR utilizes AI (codex from OpenAI) to generate code.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing Lychee-Technology:develop (a131078) with develop (469e31f)}

Summary

✅ 1138 untouched benchmarks
⏩ 1384 skipped benchmarks¹

Footnotes

1. 1384 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[0ax1]

Thanks for taking the time to look into this. There's a couple of issues around thread safety / locking, error handling and memory leaks.

If you used AI to assist in writing the code for your PR please mention this in your PR description (see: https://github.com/vortex-data/vortex/blob/develop/CONTRIBUTING.md).

[0ax1]

Why do we need a separate type (SendableClientContext) given that Send + Sync is set on ClientContext directly now?

[iceboundrock]

Because it separates ownership/lifetime semantics from thread-safe handle passing.

ClientContext is a wrapper! type with owned state and Drop logic. It is not Copy and should not be casually moved across async boundaries or spawned tasks.

On the other hand, SendableClientContext is a tiny, Copy wrapper around the raw duckdb_vx_client_context pointer with no destructor. It’s just a handle, which is ideal for passing into async or spawn_blocking code.

[0ax1]

Shouldn't we also hook into the duckdb_fs_glob for local paths? Or asked differently, should we make any assumptions at all here about globbing details of duckdb_fs_glob but rather unconditionally delegate to duckdb? Whether or not gcs is supported is now a Duckdb implementation detail.

[0ax1]

My suggestion is to just do this let file_urls = duckdb_fs_glob(..).

[0ax1]

Almost there, thanks for taking the time to address the comments!