…ing external

A thread's abandoned_data (the external-spill target) is sized once at the
global radix bits of when it first went external and then frozen, but the
global radix bits can keep growing afterwards along with the thread's own HT
data. Merging the larger HT data into the smaller, stale abandoned_data makes
RepartitionFinalizeStates compute NumberOfPartitions(new_radix_bits -
old_radix_bits) with unsigned arithmetic: new < old underflows to a huge
multiplier, indexing the partition and pin-state vectors out of bounds ->
segfault.

Fix: GrowAbandonedDataToRadixBits repartitions abandoned_data up to the current
global radix bits (the supported new >= old direction) before merging into it,
called in both the sink-phase external repartition and before the combine-phase
Combine. As defense-in-depth, PartitionedTupleData::Repartition now throws
instead of underflowing when asked to go to fewer partitions.

lance-duckdb's committed Cargo.lock pins ethnum 1.5.2, whose error.rs
fabricates a `core::num::TryFromIntError` via `mem::transmute(())`. That
assumed the type was zero-sized; it is now 8 bits, so on Rust >= 1.97 the
build fails with E0512. Rust 1.97 went stable on 2026-07-07, which is what
turned this into a CI failure here.

ethnum 1.5.3 replaces the transmutes with safe constructors. jsonb (the crate
that pulls ethnum in, via lance-arrow) requires `ethnum ^1.5.2`, so 1.5.3
already satisfies it: the fix is purely a lockfile refresh, a two-line diff
with no manifest change and no other dependency moving.

Carry that refresh as an extension patch so the build is unblocked without
waiting on upstream. The patch context is generated against the pinned
GIT_TAG cd592bc, so the tag and the patch must be bumped together.

The durable fix belongs upstream in lance-format/lance-duckdb, which has not
refreshed its lockfile; the sibling lance-format/lance repo already has.