Use saturating arithmetics for adjust_max_width

[jieyouxu]

Summary

Fixes #7147. That was introduced in #6651.

The problem

Previously in adjust_max_width we had

    // overflows whenever value < -delta
    let adjust = |value: usize| (value as isize + delta) as usize;

this will overflow (panic in debug, wraparound in release) if value < -delta. For struct_variant_width, we'd bail with a warning

`struct_variant_width` cannot have a value that exceeds `max_width`. `struct_variant_width` will be set to the same value as `max_width`

Solution

Properly use saturating arithmetics for {adjust_max_width, reduce_max_width, increase_max_width}.

Also fix wrong doc comment for increase_max_width.

Notes for the reviewer

• Best reviewed commit-by-commit.
  • Commit 1 introduces a unit test that would panic.
  • Commit 3 uses saturating arithmetic so that we don't do silly wraparound max widths.
• This is not a target/ ui test because eprintln! warning isn't easily testable, cf. eprintln! warnings are not (easily) testable #6933.
• This is related to a general class of problems cf. We don't consistently handle overflows and numeric as-casts robustly #7151 where we are not handling arithmetics that may overflow or integral casts that may reinterpret or truncate very carefully.

---

• I did not use an LLM to create a change in this PR.
• I used an LLM to create a change in this PR, and I have explained below how it was used.

I used an LLM to co-review my changes, but did not use it to create changes.

[jieyouxu]

Unfortunately I think this made it to 1.100 beta if I got my release cycle right, so we may need/want to consider a 1.100 beta backport

rustfmt +beta --version
rustfmt 1.11.0-beta (e3feeb59cd 2026-09-27)

r? @ytmimi (or another rustfmt reviewer)

[ytmimi]

@jieyouxu Yeah, let's try to get a beta backport out for this since it made it into 1.100

[ytmimi]

Added the 1.100.0 Milestone since this was backported to the 1.100.0 beta via rust-lang/rust#163547