[Mola-maker]

Closes #8386.

Rationale for this change

Display for BytesRange returns Err for zero-size ranges and for ranges whose end overflows u64. format! turns a Display failure into a panic, so BytesRange::new(0, Some(0)).to_string() panics. Display must stay total: it may only fail when the underlying formatter fails.

What changes are included in this PR?

• Display now renders ranges with no valid HTTP representation (zero size, overflowing end) as an empty string instead of returning Err; all representable ranges render exactly as before.
• to_header now builds from that rendering and returns an empty string for unrepresentable ranges, exactly as before, so no service's observable header behavior changes.
• Updated the three tests that asserted Display fails; to_header tests are unchanged.
• Noted the empty-rendering behavior in the BytesRange docs.

Are there any user-facing changes?

Yes, minor: BytesRange::to_string() (and format!) no longer panics for zero-size or overflowing ranges; it returns "". to_header() output is unchanged.

Breaking changes

None.

AI Usage Statement

• Harness: Muse (Meta personal AI agent)
• Model: Muse Spark 1.3
• Effort: no named reasoning-effort setting exposed by the harness
• Role: AI investigated the issue against current main, reproduced the format! panic with a std-only experiment, implemented the fix and updated the tests, and ran cargo test -p opendal-core --lib types::bytes_range (17 passed) and cargo clippy -p opendal-core --lib (clean). The human contributor directed the work, selected the issue, and remains responsible for the change. Assumptions and unknowns affecting review: (1) rendering unrepresentable ranges as "" is the chosen fix; the alternative of keeping Display failing and relying on to_header is what the issue reports as incorrect; (2) full workspace CI (clippy --workspace, nextest) still has to run on this PR; (3) a contributor verbally claimed this issue on 2026-10-11 but had no linked PR as of 2026-10-26.