Right-fill follows the painted background, not minus/plus-style

[igrmk]

Right-fill follows the painted background, not minus/plus-style

Problem

In side-by-side mode, when a removed (or added) line's content is repainted to a
non-default background — e.g. git's moved-line color remapped through
map-styles — the panel's trailing background fill was still painted with
minus-style (resp. plus-style). The code itself was colored correctly, but
the empty space after it carried the wrong color, leaving a stripe.

The shots below render a block git reports as moved, recolored by map-styles
to a gray background. The repro is self-contained — git's own config is
neutralized, color-moved is turned on explicitly, and delta is driven entirely by
flags — so it doesn't depend on whoever runs it (4b56fde1 is the commit that
relocated the release-verification block in this repo):

GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null \
  git -c diff.colorMoved=default log -p -M --color=always -1 4b56fde1 \
  | delta --no-gitconfig --side-by-side --width 210 \
      --minus-style 'black #d6a29f' --map-styles 'bold magenta => white #545557' \
  | sed -n '50,61p'

The trailing sed crops the output to the relocated block (the left, removed
panel).

Before

The content is gray (the map-styles remap), but each line's trailing fill runs
out in pink minus-style — a mismatched stripe after every line.

After

Content and fill share the painted background.

Cause

Painter::get_should_right_fill_background_color_and_fill_style chose the fill
for a standalone minus/plus line — the HunkMinus(_, None) / HunkPlus(_, None)
branches — as config.minus_style / config.plus_style unconditionally. That
ignores any map-styles (or color-moved) remap parse_style_sections already
applied to the content, so the fill and the content disagree.

Fix

Derive the fill from the last painted, non-newline style section of the line —
the same "last real style" the color-moved branch already keys on — and fall
back to minus/plus-style only when there is none. The fill then follows whatever
the content was actually painted (src/paint.rs).

Test

fill_style_tests::test_right_fill_follows_painted_content_for_standalone_minus
drives the fill function directly: a standalone removed line whose content is
painted to a non-minus background must yield a fill matching that background, not
minus_style. It fails on the old code and passes on the new.

Known limitation (separate issue)

A fully-blank moved line still renders in minus-style rather than the move
color. This is not a fill mismatch — the fill faithfully follows the line's
content — but a parsing-level quirk: git puts the move color only on the -
marker, which delta strips, so the blank line carries no content color left to
map. Out of scope for this change.

[igrmk]

Superseded by #2166
Closing