InnoDB table size may overflow 32-bit page counter in file space header

Following a report from a crash occurring in 10.4, confirmed to be related to InnoDB table size overflow (page counter in FSP header overflows 32-bit), a test was designed to investigate InnoDB behavior when the overflow occurs.
The test involves forging an .ibd file using perl and resizing it with the truncate call to ~4TiB (~2 ³² pages of size 1KiB each), which if the filesystem supports sparse allocation will not be physically taking up as much space.
INSERT are then done on the forged file until overflow occurs.
No server version seems to handle explicitly the overflow case, but since 10.4 used 64-bit variables to track the 32-bit value in the FSP header, whereas more recent versions use matching 32-bit variables, the failure modes are different in the two cases.
Focusing on 10.6+, it seems debug builds crash on INSERT because the overflow brings the size to be written in the FSP header to zero and an assertion is defending against that.
Release builds instead seem to be busy in a retry loop, continuously trying to allocate a new extent (request which is overflow-causing and failing) for the file.

I'm unsure that forging is correctly representing the situation of a table that "naturally grew" its size.
Anyway it seems proper handling of the page size counter reaching the 2 ³² - 1 value is missing.

Usage of ROW_FORMAT=COMPRESSED makes it easier to trigger this bug in real usage since the effective page size would be halved in the default case (which leads to maximum table size of ~32 TiB).