fix: promote a size that rounds up to a full unit in two more formatters

[rominf]

Summary

Follow-up to #503, which fixed rocm_core::format_bytes printing a size just below a unit boundary as "1024.0 KiB". Review there found the same defect in two more formatters, and this fixes both the same way.

• format_bytes_for_user (rocm binary) formats the size in the download: approved up to … line of the automations view. Sizes of 1,048,525–1,048,575 bytes printed as "1024.0 KB", and 1,073,689,396–1,073,741,823 as "1024.0 MB". They now print "1.0 MB" and "1.0 GB".
• mib / mib_pair (dashboard VRAM): 1,048,525–1,048,575 MiB, just under 1 TiB, printed as "1024.0 GiB" and now prints "1.0 TiB". The two now share one unit-picking helper, so the pair can't pick a different unit from the single value.

Unit labels and the "bytes" wording are unchanged; the KB/MB versus KiB/MiB naming is a separate question.

Why

Each formatter promoted on the raw value (>= 1024) but printed with {:.1}, which rounds 1023.95 and above up to 1024.0, so the loop stopped one unit early. As in #503, they now promote while the value as printed would reach 1024: (value * 10.0).round() >= 10_240.0.

Test plan

• Pinned boundary examples for each function, covering the last input that stays in the smaller unit and the first that rounds up. They fail before the fix and pass after.
• The same two-edge property as fix(disk-space): promote a size that rounds up to a full unit #503's format_bytes_renders_a_size_in_its_own_unit, pointed at format_bytes_for_user, at mib, and at mib_pair's total.
  • Upper edge: below the top unit, the printed value is under 1024.0.
  • Lower edge: above the base unit, it is at least 1.0, and the next smaller unit would have printed 1024.0 or more.
• proptest is added as a dev-dependency of rocm and rocm-dash-tui, with the version and features rocm-core already uses. No new crate enters the lockfile, and nothing ships.
• The automations render test now uses a 1,048,575-byte download cap, so the user-facing download: approved up to 1.0 MB line is checked at the boundary through the real renderer.
• Mutation-checked:
  • Restoring the old raw >= 1024.0 comparison fails both the examples and the properties, at 1,048,525.
  • Promoting slightly early fails the lower edge.
  • Both were checked with the saved seeds removed, so the generator finds them on its own.
• No new e2e scenario: the download: approved up to line is only reached through the assistant's in-process, read-only automations command, and no current scenario seeds automation proposals. Coverage is the render-level test above.
• Verified locally: cargo fmt --check, cargo clippy --workspace --all-targets -D warnings, cargo test -p rocm --bin rocm, cargo test -p rocm-dash-tui --lib (ui::format), cargo test -p xtask, cargo xtask manifest --check.

Independent of #503's code; it can land in either order.

• Bug fix: no xfail rows reference this area.
• No new subcommand or subsystem.
• The changed output line is asserted with its rendered value through the real renderer.

[jussielo-amd]

Nice, tightly-scoped fix — matches the #503 pattern exactly where it needs to. The promoted_mib_unit extraction for mib/mib_pair is a good call: it structurally prevents the pair from picking a different unit than the single value would.

Checked the boundary math by hand and ran both test suites locally (rocm-dash-tui's ui::format and rocm's format_bytes_for_user tests) — all pass, including the new proptest properties and their saved regression seeds. Updating the automations render test to hit the boundary through the real renderer instead of just the helper function is a nice touch.

One non-blocking FYI: apps/rocm/src/main.rs::format_bytes (behind rocm storage) already had this same defect fixed, but with a different style (a hardcoded 1023.95 cutoff vs. the rounded-tenths loop used here) — pre-existing, out of scope for this PR, just worth a note for whoever's next in that neighborhood.