ecm fix fix partial extend

[ecm-pushbx]

Fixes #243 and properly fixes #241

This updates the commit from #242 with a correction.

I also added two comments on unexpected corner cases around writes of length 0 trying to extend more than actually needed. There is possibly a fragmentation source if a file is extended to fall exactly on a cluster boundary with 0-length write.

[ecm-pushbx]

I'm not too happy about the calculation in

kernel/kernel/fatfs.c

Lines 1031 to 1035 in dd2293f

	fnp->f_dir.dir_size =
	(((ULONG)fnp->f_cluster_offset + 1)
	* (ULONG)fnp->f_dpb->dpb_secsize)
	<<
	fnp->f_dpb->dpb_shftcnt;

The problem is that f_cluster_offset (which directly maps to relative current cluster in the SFT) is incremented to 1 when the second cluster has been allocated, so f_cluster_offset + 1 gives the currently allocated amount of clusters during the extend loop.

OH. I think my current and prior patches are both super wrong in one aspect. They will modify the file size when scanning a file (read or write) before EOF. Proper fix upcoming.

[ecm-pushbx]

Test case to reproduce error: https://pushbx.org/ecm/test/20260422/testtrun.sld

e 200 "A:\test.dat" 0
f 400 l 400 38
a
 mov ah, 3C
 mov cx, 0
 mov dx, 200
 int 21
 xchg bx, ax
 mov ax, 4200
 mov cx, (#10240 >> 10)
 mov dx, (#10240 & FFFF)
 int 21
 mov ah, 40
 mov dx, 400
 mov cx, 0
 int 21
 mov ah, 68
 int 21
 nop
 mov ax, 4200
 xor cx, cx
 xor dx, dx
 int 21
 mov dx, 800
 mov ah, 3F
 mov cx, 380
 int 21
 int3
 mov ah, 68
 int 21
 nop
 int3
 nop
 jmp 100
 .