Unreleased version after creating v5.0.0-rc.1

…6389)

## Summary

- Replace `panic!()` in `initial_upload_size()` with a warn-and-clamp
fallback when `LANCE_INITIAL_UPLOAD_SIZE` is set outside the valid
`[5MB, 5GB]` range, so misconfiguration can't crash the process
- Extract `MAX_UPLOAD_PART_SIZE` constant for the 5GB upper bound
- Extract `clamp_initial_upload_size` as a pure helper and add boundary
unit tests

## Motivation

Setting `LANCE_INITIAL_UPLOAD_SIZE` to a value outside the valid range
previously crashed the entire process via `panic!()` — a
disproportionate response to a perf-tuning env var misconfiguration. Per
review feedback (#6389 (comment)), a crash (or even a propagated
`Result`) forces every caller to handle a purely operator-side mistake.
Clamping to the valid range and emitting a single warning lets the
workload proceed and surfaces the misconfiguration to operators. This
also matches the silent-fallback behavior of the sibling env vars
`LANCE_UPLOAD_CONCURRENCY` and `LANCE_CONN_RESET_RETRIES`.

## What Changed

**`initial_upload_size()`**: Return type stays `usize`. Out-of-range
values are clamped into `[5MB, 5GB]` and a single `tracing::warn!` is
emitted with `requested` and `clamped` fields. The existing `OnceLock`
cache guarantees the warning fires at most once per process, so no
separate rate-limiting logic is needed. Non-numeric and unset values
continue to fall back silently to the 5MB default.

**`clamp_initial_upload_size(raw) -> (usize, bool)`**: Pure helper
extracted for testability. Returns the clamped value and whether
clamping occurred.

**`MAX_UPLOAD_PART_SIZE`**: New constant for the 5GB upper bound.

## Behavioral Equivalence

| Input | Before | After |
|-------|--------|-------|
| Env not set | 5MB default | 5MB default |
| Non-numeric (e.g. `"abc"`) | 5MB default | 5MB default |
| Valid integer in `[5MB, 5GB]` | Returns the value | Returns the value
|
| Integer `< 5MB` | **`panic!()`** | Clamped to 5MB + `warn!` (once) |
| Integer `> 5GB` | **`panic!()`** | Clamped to 5GB + `warn!` (once) |

No API changes — `ObjectWriter::new()` signature is unchanged.

## Test plan

- [x] New boundary unit tests: below min, min boundary, in-range, max
boundary, above max, `usize::MAX`
- [x] `cargo test -p lance-io --lib object_writer` — 7 tests pass
- [x] `cargo clippy -p lance-io --tests -- -D warnings` — clean
- [x] `cargo fmt -p lance-io -- --check` — clean
- [x] `cargo check --workspace --tests` — full workspace compiles

Upgrades the pinned Rust toolchain from 1.91.0 to 1.94.0.

The only code change needed was boxing two futures in
`build_partial_fixture` in the `distributed_vector_build` bench, where
1.94's stricter layout computation overflowed the default recursion
limit. Boxing makes the awaited futures' sizes constant (a pointer),
breaking the recursion.

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

## Feature

### What is the new feature?
This PR adds native `float16` and `float64` support for `IVF_FLAT` and
`IVF_HNSW_FLAT`.

### Why do we need this feature?
Flat IVF indexing previously only worked end to end for `float32`. That
meant users could not build, merge, reload, and query flat IVF indexes
on `float16` or `float64` vectors without running into
`Float32`-specific assumptions in flat storage, writer initialization,
and merge/query paths.

### How does it work?
The implementation makes flat IVF paths dispatch on the actual Arrow
element type from stored flat data instead of assuming `Float32`.

- `FlatFloatStorage` now dispatches distance calculators for `float16`,
`float32`, and `float64`.
- Query/training helpers that previously special-cased `Float32` now
accept the native float dtype where needed.
- Tests now cover flat storage distance, partition serde roundtrip, IVF
create/query/remap, and distributed merge behavior for `float16` /
`float64`.

## Validation

- `cargo fmt --all`
- `cargo check -p lance-index --lib`
- `cargo check -p lance --lib`
- `cargo test -p lance-index test_flat_float_storage_distance_f16 --
--nocapture`
- `cargo test -p lance-index
test_merge_ivf_flat_preserves_float64_schema -- --nocapture`
- `cargo test -p lance test_build_ivf_flat -- --nocapture`
- `cargo test -p lance test_create_ivf_hnsw_flat -- --nocapture`
- `cargo test -p lance test_create_ivf_flat_f16 -- --nocapture`

## Benchmark Note

I also benchmarked float32 `IVF_FLAT` before vs after, no obvious
performance diffs