feat: catch panics at the FFI boundary and report LANCE_ERR_PANIC (#61)

[u70b3]

Summary

POC implementation of the panic-handling strategy from #61 (consensus of @jja725, @zhangstar333, @u70b3 in the issue discussion):

• Drop panic = "abort" from the release profile. Under Rust 1.81+ an unwinding panic out of an extern "C" fn is a defined abort, never UB — any path we miss can no longer be unsound, only an abort.
• Catch at every FFI boundary: all 66 entry points now run under catch_unwind — 54 via the extended ffi_try! arms (null / neg / void / generic errval, covering the 0-sentinel integer shape), 3 hand-rolled guards on the scanner stream ops, an async task guard plus an entry guard around the async entry's whole call-time setup, 6 swallow_unwind close/free paths, and 2 provably infallible TLS accessors. Caught panics map to the new LANCE_ERR_PANIC = 9 (ABI-compatible enum append; matches the header's LANCE_ERR_* convention), with the message extracted UniFFI-style (&str/String downcast, NUL-sanitized).
• Poisoned scanner handles: a caught panic flips an Arc<AtomicBool> shared with the exported-stream wrapper and the async task; later lance_scanner_* calls fail with LANCE_ERR_PANIC ("scanner is poisoned by an earlier panic"). lance_scanner_close stays poison-check-free so memory is always freed.
• Dataset handles stay usable (credit @zhangstar333 for the RwLock-poisoning catch): with_mut is now clone-execute-swap under the write lock with catch_unwind + resume_unwind — the panic keeps its original payload for the entry guard, in-memory state rolls back by never swapping, and lock access is poison-tolerant (a single Arc pointer swap can never tear).
• Exported Arrow streams (the issue's central gap): the stream is exported through a reader-level GuardedReader whose next() wraps the complete handle.block_on(stream.next()) operation — a stream-level guard catches too late, because Handle::block_on itself panics before any poll when the consumer's thread is driving a Tokio runtime. A mid-iteration panic becomes exactly one Err item — which arrow-rs's exported get_next maps to a nonzero return + get_last_error, then EOS, i.e. the Arrow C stream error contract with no C-side changes — and poisons the owning scanner. GuardedReader::drop detaches the inner stream and drops it under catch_unwind, so a cleanup panic on arrow-rs's extern "C" release path is contained (best-effort leak) instead of aborting the host. Worth upstreaming into lance_io::ffi::to_ffi_arrow_array_stream so lance-java benefits.
• Async path: DispatcherMessage now carries (code, message), installed on the dispatcher thread's TLS immediately before each callback (fixes async errors dying on a Tokio worker's TLS — credit @zhangstar333); the whole spawned future runs under catch_unwind().await, so a task panic still delivers the -1 callback instead of hanging the C caller, and poisons the scanner; and the entry guard around call-time setup (validation, scanner building, runtime access, spawn) delivers the same -1 + poison even when setup itself panics. Host callbacks are explicitly non-unwinding by contract (lance.h): a panicking extern "C" callback aborts at its own boundary before any caller-side guard can run, so the dispatcher's catch_unwind is only best-effort protection for extern "C-unwind" Rust hosts — never part of the contract.
• Honest docs (lance.h): double panics, panics in Drop during unwind, stack overflow, and allocation failure still abort; close/free (including Arrow stream release) is best-effort and may leak the remainder; hosts should fail the query rather than retry a poisoned handle; callbacks passed into the library must not panic.

Evidence / tests

• tests/panic_stream_guard.rs (the PoC from the issue discussion, now tracked): an unguarded export dies by SIGABRT in a child process even under panic = "unwind"; the guarded export drives the full Arrow C stream error contract end to end through raw get_next pointers — including when get_next is called from a thread driving a Tokio runtime (where Handle::block_on panics before any poll) — and a panicking destructor reached through the raw release pointer is contained. Both child-process regressions assert a clean exit AND that the panic really fired (via the panic hook's stderr).
• Rust unit tests covering: guard-arm shapes, poison behavior on all scanner entry-point shapes, with_mut rollback on a genuinely poisoned lock, dispatcher TLS transport + stale-error clearing, reader-level fusing / NUL sanitization / runtime-driving-thread containment / drop containment, and an injectable-setup test proving a scan_async setup panic poisons the handle and dispatches exactly one LANCE_ERR_PANIC completion.
• Full suite: 296 passed / 0 failed; cargo clippy --all-targets -- -D warnings clean; cargo fmt clean; C/C++ compile-and-run tests pass (GCC 13.3.0).

Deliberate minor bugfixes folded in

• lance_dataset_version now clears the thread-local error on success, like every other guarded fn.
• lance_dataset_write wraps the shared inner directly instead of bare-forwarding to lance_dataset_write_with_params (an outer guard would have cleared the inner guard's TLS error).

Out of scope / follow-ups

• Index segment builders (src/index_segment.rs) live on the unmerged distributed-index branch; they need the same poison treatment once that lands.
• Upstreaming GuardedReader into lance-io so lance-java benefits too.
• Optional chained panic hook for backtraces (the default hook already prints to stderr).

[lance-gatekeeper]

✅ Gate recommendation: approve.

The follow-up only fixes the private helper reference in module documentation, with no runtime change. The previously verified panic guards and callback/error contracts remain intact.