Panic when casting large Decimal256 to f64 due to unchecked `unwrap()`

[kosiew]

Describe the bug

When attempting to cast a large Decimal256 value to Float64, Arrow panics due to an unchecked .unwrap() on a None result from to_f64(). This occurs because some large Decimal256 values cannot be represented accurately as f64, and the conversion fails silently, leading to a runtime panic.

To Reproduce

This was encountered via DataFusion

> create table tt(v1 decimal(50,2));
> insert into tt values (133333333333333333333333333333333333333333333.34);
> select v1 + 1.5 from tt;

thread 'main' panicked at /Users/yongting/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/arrow-cast-55.2.0/src/cast/mod.rs:894:38:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The panic comes from

arrow-rs/arrow-cast/src/cast/mod.rs

Line 894 in 3126dad

|x: i256| x.to_f64().unwrap(),

Expected behavior

Avoid using .unwrap() in the cast logic.
Potential alternatives:

Gracefully propagate the error:

|x: i256| x.to_f64().ok_or_else(|| ArrowError::CastError("Failed to convert Decimal256 to f64".to_string()))

Additional context

This issue was discovered via SQLancer fuzzing, which uncovered this unsafe conversion path. Avoiding panics in core Arrow casting logic would improve robustness in downstream libraries like DataFusion.

[alamb]

label_issue.py automatically added labels {'arrow'} from #7887