Fix EXT4 extent offset double-counting causing block address overflow

[Ronitsabhaya75]

Closes #441

current behavior:

EXT4 filesystem corruption occurs when creating large files in containers, causing block addresses to exceed maximum inode values. This results in errors like:

EXT4-fs warning (device vdb): ext4_block_to_path:105: block 1710731624 > max in inode 21209237

The fix:

Remove the pre-added offset. Connect to the correct block address immediately by passing blocks.start directly, allowing offset to be applied once inside fillExtents. This ensures block addresses remain within filesystem bounds for files of any size.

[dcantah]

There's no need to include the comment

[Ronitsabhaya75]

@dcantah ill remove the comment thank you so much

[dcantah]

@Ronitsabhaya75 This does look wrong, but do you actually see this fixes these warnings? I remember trialing a very similar fix a week or so ago and didn't seem like much changed. I haven't had much time to dig back in

[Ronitsabhaya75]

@dcantah I haven't been able to test it yet because I'm on macOS 15.6 and the project requires macOS 26+.

However, I'm confident this is the root cause based on the math:

The bug: Line 1137 passes start: blocks.start + offset, then line 1053 adds offset again:

extentStart = (blocks.start + offset) + (offset + i * MaxBlocksPerExtent)
            = blocks.start + 2*offset + ... 

For extent block iteration 5231: offset = 856,842,240

Double-counted: extentStart = 1,713,685,480 (matches the 1,710,731,624 error!)

Filesystem max: 134,217,728 blocks (way exceeded!)

[dcantah]

The math I agree with, I just vaguely remember still seeing these warnings even with a similar (possibly the exact same) fix. I'll give it a whirl

[Ronitsabhaya75]

The math I agree with, I just vaguely remember still seeing these warnings even with a similar (possibly the exact same) fix. I'll give it a whirl

for sure Um we can test it and check if there are warnings i can have deeper look into it. thank you @dcantah for reviewing