Bug Description

The read_multiple_ranges function returns incorrect hash values for multi-line ranges due to inconsistent end value handling.

Problem

• Function uses 0-based end index for slicing lines[start:end]
• But returns the same end value as 1-based line number in response
• This causes hash mismatches when the returned range is used later

Example

Range 1-3 (1-based):

• Slices lines[0:3] → content: "line1\nline2\nline3\n"
• Returns end: 3 but should represent lines 1-3, not 0-based index 3

Impact

Hash validation fails for multi-line operations causing "Content hash mismatch" errors.

Fix Available

I have a fix ready that separates slicing logic from response values.