editor: Do not reserve inline blame scroll width when blame is in the status bar (#61422)

## Problem

When `git.inline_blame.location` is `status_bar` (anything other than
`inline`), nothing is painted inline at the end of the line — yet the
horizontal scroll range still reserves the longest row's inline blame
width (introduced in #23374), letting the editor scroll into blank space
when a line is long enough to scroll. Reported in #24752 (e.g.
@Nemesis19's comment: still reproduces with `location: status_bar`).

## Fix

Skip the blame width reservation in the scroll range when the blame
location isn't `Inline` — one guard in the `longest_line_blame_width`
closure in `element.rs`. This is independent of the soft-wrap fix for
#24752 (#61319) and can land on its own.

## Test

`test_status_bar_blame_location_reserves_no_scroll_width` asserts that,
with a long line and no soft wrap, moving blame from inline to the
status bar shrinks the horizontal scroll range (the reservation is
dropped). It uses a fixed-width test `BlameRenderer`, since the default
test renderer returns `None` and never exercised the reservation.

Release Notes:

- Fixed inline git blame reserving horizontal scroll space even when
blame is displayed in the status bar
1817b43c80Vlad Gaevsky committed on 7/22/2026, 2:32:56 PM· committed by GitHubparent3f7f056
1 file changedLine totals unavailable