Mark first block before matching content as changed in line ranges mapping

[bysiber]

In _calculate_lines_mappings, when the first matching_blocks entry doesn't start at offset 0, the content before it is different between original and modified. This block should be marked as is_changed_block=True, but it's currently marked False.

What goes wrong

The adjusted_lines function uses is_changed_block to decide how to remap line ranges:

• For unchanged blocks, it applies a linear offset
• For changed blocks, it expands to the full block extent

When the first changed block is mislabeled as unchanged, a linear offset is applied instead of block expansion. For example, if the original file has 5 lines changed at the top that become 3 lines after formatting, a --line-ranges 1-5 would compute the new range as (1, 5) via offset instead of the correct (1, 3) via block expansion. The range extends past the actual modified content.

The else branch (for i > 0) correctly marks inter-block gaps as is_changed_block=True — this first-block case was just missed.

[JelleZijlstra]

Thanks! Could you add a unit test for this behavior and a NEWS entry describing the user-visible change?

[github-actions]

diff-shades results comparing this PR (219ff2d) to main (5518079):

--preview style: no changes

--stable style: no changes

---

What is this? | Workflow run | diff-shades documentation

[bysiber]

Added both — unit test in test_ranges.py (test_first_block_changed) and a CHANGES.md entry under Stable style. The test verifies that changes in the first block before any matching content are correctly included in the adjusted line ranges.

[cobaltt7]

@bysiber Please review the test failures