- Take &str/&client in send_multipart_chunked instead of owned String
- Early-return on empty partitions instead of staging a schema-only part
- Split the long chunking fn into build_part_request / send_part_request /
  send_one_part helpers

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

The client read timeout covers the request-body upload, not just the
response, so a slow or throttled upload of a single large part can hit it
even while making progress. Splitting only by bytes doesn't help when
throughput is low.

Add a per-part wall-clock budget (max_request_duration, env
LANCE_CLIENT_MAX_REQUEST_DURATION, default read_timeout/2) and cut a part
on whichever of bytes/time is reached first. Raise the byte default from
1 GiB to 8 GiB so a part holds at least one full Lance data file
(1M rows) and fragments aren't split undersized across parts; the time
cut keeps large parts from risking the read timeout.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Add unit tests for the max-bytes / max-duration resolution helpers
(config precedence, env parsing, invalid-env errors, zero-disables,
default derivation) and for multipart chunking behaviors that were
previously untested: empty partitions staging nothing, distinct
upload_part_id per part, per-partition chunking, and surfacing the
original input error over an induced HTTP error.

Also fold the per-request-constant arguments of the multipart part
helpers into a PartRequestCtx struct, dropping the
too_many_arguments allows, and document the count-0 result, per-part
overwrite mode, join!-not-spawn choice, and the Option semantics that
invert between the config and resolved-client layers.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Address review feedback:

- The chunked multipart path recorded a part's bytes only after the whole
  part finished uploading, so the progress bar jumped once per part and
  looked like it was stalling and restarting. Push byte recording down
  into the per-part producer stream so progress advances as each chunk is
  produced, matching the non-multipart path. send_one_part now records on
  the tracker and returns only whether the input ended.

- The max-bytes-per-request budget was a usize, so the 8 GiB default
  overflows on 32-bit targets. Use u64 throughout (config, resolution,
  client, exec) so the default is representable everywhere and the
  per-part byte accumulator cannot overflow.

Add a test asserting progress is reported multiple times, monotonically,
within a single part.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

An explicit write_parallelism forced the multipart path even for
fully empty input. Since an empty partition stages no part, an
all-empty multipart write left nothing for `complete` to commit,
silently dropping `mode=overwrite`. Peek the input regardless of
write_parallelism and fall back to the single-request path (which
always sends a schema-only request) when it's empty.

Addresses review feedback on lancedb#3630.

Rebasing onto upstream/main pulls in a Lance/DataFusion bump where
ExecutionPlan no longer declares as_any() as a trait method (downcast
goes through the Any supertrait coercion instead, as the rest of the
codebase already does). The test-only ErroringExec mock still defined
it explicitly, which no longer compiles.