Steam app data files using twice the expected disk space on Mac OS Monterey

My son wanted a game from steam, which said it required 40GiB disk space. Sure, done. Installed, but I noticed it was using 80GiB disk space, but didn't think much of it, until it decided to auto-patch and ran out of disk space. Digging into the install, there's a single file, as reported by the Finder & ls, that is ~37GiB in size. It is using ~75GiB disk space according to the Finder and du.

sh$ pwd
/Users/zz/Library/Application Support/Steam/steamapps/common/Tropico 6/Tropico6.app/Contents/UE4/Tropico6/Content/Paks
sh$ ls -l pakchunk0-MacNoEditor.pak 
-rwxr-xr-x  1 zz  staff  40001130623 31 Mar 17:12 pakchunk0-MacNoEditor.pak
sh$ du -k pakchunk0-MacNoEditor.pak 
78127216        pakchunk0-MacNoEditor.pak
sh$ ls -lh pakchunk0-MacNoEditor.pak
-rwxr-xr-x  1 zz  staff    37G 31 Mar 17:12 pakchunk0-MacNoEditor.pak
sh$ du -h pakchunk0-MacNoEditor.pak
 75G    pakchunk0-MacNoEditor.pak

Searching around, I see mention of timemachine snapshots (tmutil listlocalsnapshots shows none), sparse files (no, they generally show the opposite, large eof and small usage), APFS compression (stat -f %f pakchunk0-MacNoEditor.pak returns zero, and afscexpand does nothing). What could this be? A bad fallocate(2) by steam (does Mac OS X even have that)? A copy of the file in another logical fork? Multiple write heads leading to some weird internal fragmentation? Something else? What weird thing has Apple managed to do this time? So, the question is, what could possibly cause a 40GB file to require 80GB on Mac OS X? Is this an APFS bug? PS: fwiw, a Duplicate+Delete+Rename in the Finder fixed this one file (ie. released 40GB disk space), and I assume thanks to the APFS clone functionality, did so without copying any data. And on a second attempt, I noticed that **just doing the duplicate** released the space.