fix(datafusion): coerce numeric literals to and from Float16

[LuciferYang]

Problem

Fixes#8846.

A Float16 scalar column can be written and scanned, but no numeric literal ever reaches it, so it cannot be filtered at all:

Invalid user input: Error resolving filter expression value < 0.0: Invalid user input: Received literal Float64(0) and could not convert to literal of type 'Float16'

safe_coerce_scalar had no Float16 arm in either direction, and the second direction fails silently. Adding the DataType::Float16 targets alone makes filters work, but maybe_scalar then calls safe_coerce_scalar on a literal the planner has already coerced to Float16, so without a ScalarValue::Float16 source arm the predicate drops to a refine filter. Rows come back correct, so only the plan shows it. On a Float16 column with a BTree index, at 6 rows and at 5000:

before: LanceRead: ... full_filter=value = Float16(1), refine_filter=value = Float16(1)
after: LanceRead: ... full_filter=value = Float16(1), refine_filter=--
ScalarIndexQuery: query=[value = 1]@value_idx(BTree)

A Float32 column of the same shape and query already planned the second form, which is the control that says this is a Float16 gap and not a row-count heuristic.

What this changes

DataType::Float16 is now a target in all ten numeric source arms, and ScalarValue::Float16 is a new source arm reaching Float16, Float32 and Float64.

Out-of-range literals are rejected, not saturated. This differs from the Float64 to Float32 arm next to it. f16 overflows at 65520, which an ordinary literal passes, and safe_coerce_scalar cannot see the operator, so it cannot saturate only where saturation is harmless: collapsing 1e-30 to zero would make value = 1e-30 match real zeros. The cost is that value < 100000 now errors where saturating would have returned every finite row. I took the error over the wrong row set. The Float32 arm is left alone because reaching its boundary takes a literal above 1e38.

Rounding is done by neighbour comparison, because half rounds incorrectly in both of its paths: the software one truncates the low 32 bits of the f64 mantissa before rounding (half-rs#151), and the x86 hardware one rounds through f32 first (half-rs#116). nearest_finite_f16 starts from the software answer, which at least does not vary by target, then picks the true nearest among it and its two bit-neighbours, tie to even. Widening f16 back to f64 is exact, so those three comparisons decide it. = 2049.001 now coerces to 2050 where half gives 2048.

Overflow is decided by value.abs() >= 65520.0 rather than by half. 65520 is the exact IEEE tie above the largest finite f16 and is exactly representable in f64, so the check does not inherit the platform-dependent boundary.

The f16 grid itself stays inexact: past 2048 it is coarser than the integers, so = 2049 matches rows holding 2048, the same way the Float32 and Float64 arms are inexact on finer grids.

Out of scope

IndexType::BloomFilter rejects Float16 outright, so the Float16 cases of test_query_float and test_query_float_special_values run BTree, Bitmap and ZoneMap only. test_bloom_filter_rejects_float16 pins that refusal so the skip cannot outlive it.

Test plan

• cargo test -p lance-datafusion (176 and 5 passed). 24 new cases over safe_coerce_scalar: every numeric literal type reaching Float16, the range and tie edges pinned as raw bits, non-finite passthrough, both zeros keeping their sign. test_f16_rounds_to_nearest_even_across_the_whole_range is the one to read: for each of the 31743 adjacent finite f16 pairs it asserts the midpoint and the two f64 values either side, with expectations stated rather than recomputed by the code under test. Stubbing the correction back out to from_f64_const makes it fail.
• cargo test -p lance-index (1187 and 9 passed). test_float16_column_reaches_its_index drives Planner::parse_filter and create_filter_plan so it runs the production coercion order; deleting the ScalarValue::Float16 source arm turns all four cases red. Built on check_with_schema it would not have, because that helper skips type coercion and so exercises the target arm instead.
• cargo test -p lance --lib (3300 passed)
• cargo test -p lance --test integration_tests --features slow_tests -- --test-threads=1 (54 passed). --features slow_tests is required: mod query is behind that gate, so without it the new tests match nothing and cargo still exits 0. The Float16 case of test_query_float_special_values is new; fix: make float filters treat -0.0 and 0.0 as the same value #6236 already carried the Float16 branch of its signed-zero rewrite, and this is the first coverage that reaches it. Reverting expr.rs to main makes that case fail with the original coercion error while Float32 and Float64 stay green.
• cargo clippy --all --tests --benches --features slow_tests -- -D warnings clean, cargo fmt --all -- --check clean

[LuciferYang]

cc @Xuanwo FYI

[LuciferYang]

The red windows-build is not this diff. It panics on debug_assert_eq!(acc as u64, total) in PrefixSums::from_deltas during an IVF_HNSW_SQ index build, which this change cannot reach: it touches Float16 literal coercion in lance-datafusion/src/expr.rs, the scalar-index expression path, and one query test. Filed as #8947.

[lance-gatekeeper]

✅ Gate recommendation: approve.

The main-branch merge leaves the reviewed Float16 patch unchanged. Deterministic nearest-even coercion, scalar-index reachability, and indexed/unindexed signed-zero coverage remain intact on the updated base.