[FFI] Fix headers-provider use-after-free via ownership transfer

[zlata-stefanovic-db]

Summary

Fixes a use-after-free where a custom HeadersProvider could be freed by the wrapper (Go/C++) while a Rust worker thread was still inside a synchronous get_headers() callback during connection recovery. Cooperative abort() cannot preempt a synchronous FFI call, and close() waited only SHUTDOWN_TIMEOUT_SECS = 1 before aborting, so a slow provider (e.g. one fetching/rotating a token) racing teardown could be invoked on freed memory.

Approach: ownership transfer at the FFI boundary

The C FFI now takes ownership of the provider user_data. zerobus_sdk_create_stream_with_headers_provider / zerobus_sdk_create_arrow_stream_with_headers_provider gain a nullable free_user_data destroy callback. CallbackHeadersProvider invokes it from Drop, which runs only after the last Arc referencing the provider drops — and the supervisor task holds its own Arc clone across the in-flight get_headers() call, so the destroy is guaranteed to run only after any synchronous callback has returned. The provider Arc is constructed before any fallible work, so free_user_data fires exactly once on every path (success after the last reference drops; failed create before returning). Wrappers hand ownership across and never free user_data themselves.

Changes by layer

• Rust FFI (rust/ffi): free_user_data param + Drop-based destroy (panic-contained via catch_unwind); regenerated zerobus.h; ownership/thread-safety docs.
• Go (go/ffi.go, go/arrow_ffi.go): hands the cgo.Handle to the FFI via goFreeHeadersProvider; removes the per-stream handle registry.
• C++ (cpp/): passes a heap std::shared_ptr<HeadersProvider> + zerobus_cpp_headers_free destroy trampoline; Stream/ArrowStream no longer keep the provider.

Scope: why only Go and C++

The bug class is specific to passing a borrowed user_data across the C FFI while the core holds a raw pointer. The other consumers are not affected:

SDK	Provider bridge	Affected?
Go, C++	borrowed raw pointer / handle freed on close	Yes — fixed here
Python	HeadersProviderWrapper owns a PyObject, handed as an owned Arc	No — Rust's Arc controls lifetime
TypeScript	headers resolved once at create → StaticHeadersProvider	No — no live JS object across FFI
Java	no custom headers-provider feature (OAuth only)	No — feature absent

Tests

• Rust: free_user_data fires once on Drop and on failed create; null destroy is a no-op; and a teardown test reproducing the recovery-vs-teardown race (a blocking in-flight get_headers on one Arc clone while another drops) asserts the free is deferred until the callback returns.
• Go: goFreeHeadersProvider releases the cgo.Handle.
• C++: trampoline dispatch + free destroys the provider; null tolerance. Passes under ASan.

All 82 Rust FFI tests and 6 C++ tests pass; changelogs updated for ffi/go/cpp.

Breaking change (FFI)

The two create-with-provider C signatures gain a free_user_data parameter — a non-additive zerobus.h change. Filed under Breaking Changes in rust/ffi/NEXT_CHANGELOG.md.

Follow-up required before Go picks this up

This changes the FFI signature, so an FFI release (ffi/v*) must land and regenerate all five platform libzerobus_ffi.a archives in go/lib/ before the Go SDK can consume it. The committed archives are intentionally left at their pre-PR builds (the locally-rebuilt one exceeded GitHub's 100 MB limit and would have been an inconsistent single-platform artifact). Go CI's cross-SDK job builds the FFI from local Rust source, so it validates this PR without the prebuilt libs.

Draft — open items

• Consider whether Go should nil-check the provider before cgo.NewHandle (C++ already throws on null) — pre-existing asymmetry, non-blocking.