Support partial last EXT4 block group

[zeel2104]

Summary

Fixes #647 by supporting a partial final EXT4 block group.

The formatter previously rounded filesystem sizes up to the next block group boundary, so a requested 160 MiB filesystem became 256 MiB. This change keeps the requested size, reports the actual filesystem block count, and marks blocks outside a short final group as used in the bitmap without counting them as filesystem blocks.

Testing

• swift test --filter ContainerizationEXT4Tests

[zeel2104]

@wlan0
Hi, I resolved the issue which was occurring in CI because of not signing the commit
It is ready to be reviewed again

[wlan0]

@zeel2104 thanks for the PR!

I think this still has an edge-case layout bug for very short final groups.

The new code allows any non-zero remainder in the final block group, but this loop still places the added group’s bitmap blocks at:

    group * blocksPerGroup + inodeTableSizePerGroup
    group * blocksPerGroup + inodeTableSizePerGroup + 1

For the 160 MiB case the final group has 8192 blocks, so this is fine. But for a size like 128 MiB + 4 KiB, group 1 has only 1 filesystem block. WithinodeTableSizePerGrouparound 512, the descriptor points to bitmap blocks outside s_blocks_count, and the write seeks beyond the declared filesystem/image size.

Could we either:

1. round up only the tiny remainder case so the last group has at least inodeTableSizePerGroup + 2 blocks, or
2. explicitly lay out the last group’s metadata somewhere valid and set the required feature bits if that depends on flex_bg-style placement?

Please add a regression test around the boundary, e.g. minDiskSize: 128.mib() + 4.kib(), checking both file size and descriptor bitmap/table locations are < superblock block count.

[wlan0]

There is still a layout bug

#717 (comment)