os.statvfs() reports negative free space on littlefs (lfs2) in certain conditions

On a 1MB lfs2 partition, if I create a file about 700kb, then close and re-open it, os.statvfs() shows a negative amount of free space. The following code for the pyboard d-series demonstrates this - the first statvfs() with the file closed shows 76 free blocks, while the second call to statvfs() after re-opening the file shows -96 blocks

### WARNING - this code will delete all files and change your partitions on your micropython device
import os, pyb, time
os.umount('/flash')
p1 = pyb.Flash(start=0, len=1000*1024)
p2 = pyb.Flash(start=1000*1024, len=1000*1024)
os.VfsFat.mkfs(p1)
os.VfsLfs2.mkfs(p2)
os.mount(p1, '/flash')
os.mount(p2, '/bak')

part='/bak'
filename = part + '/foo.bin'
file_size = 702000
f = open(filename, 'wb+')
[f.write('d' * 100) for i in range(file_size//100)]
f.close()
print(os.statvfs(part))  # shows 76 free blocks
f = open(filename, 'rb+')
print(os.statvfs(part))  # shows -96 free blocks
f.seek(0)  # takes several seconds to return
f.write('some data')
f.close()  # raises OSError 28 (out of space)

I've tested this on both pyboard and ESP32, with the same results. I've also tested the littlefs-fuse implementation of littlefs, and it does not show a negative free space result, but does run out of space in a similar way.

Start by running the provided reproduction on a pyboard or ESP32 and inspect the os.statvfs() path for littlefs (lfs2). Compare the closed-file and reopened-file results, then verify that free space is not reported as negative and that the demonstrated write behavior is corrected without breaking the out-of-space case.