Fix chunk loading for region files with unpadded sectors

[terbin]

Fixes #388

Check actual chunk data length instead of full sector allocation when validating chunk boundaries. Some exporters like WorldTools don't pad sectors to 4096-byte boundaries, causing valid chunks at the end of region files to be rejected.

Changes

• Read 5-byte chunk header to get actual compressed data length
• Validate actual data fits in file (not full sector allocation)
• Map only the bytes actually needed

Testing

Tested with WorldTools 1.2.4 exports, Minecraft 1.20+ (DataVersion 3700).

[terbin]

Added a fix to skip map_*.dat files when loading structures - worlds with thousands of in-game maps (I have some with 20k map-art .dat files) were slow to load because these files were being parsed even though they never contain structure data.

[EtlamGit]

Sorry for late reaction, I'm quite busy at the moment.
But I have seen your issue and PR and will try to take a look as soon as possible.

Your explanation also sounds reasonable.

[terbin]

Hey Etlam, thanks for your reply. There is absolutely no urgency. I am using the fix locally and it's working for me <3

[EtlamGit]

I finally found time to look into this (but still struggle to get my Qt build environment running again after Windows 11 update).
Sorry again for the long delay.

I'm fine with all these changes.

Comments:

• It is not necessary to map a header of 5 bytes, as you only use the first 4.
  But leave it like it is. With 24w04a Mojang introduced a new compression mode and this might be a good place to switch code for support of multiple compression algorithms. But we might also move the detection into NBT() constructor.
• You mixed 2 topics in one PR. If have seen that, the changes are fine and reasonable, so everything is ok.
  But next time, try to use 2 PRs for 2 topics as then it is easier to distinguish what belongs to what topic.

[EtlamGit]

It is not necessary to map a header of 5 bytes, as you only use the first 4.
But leave it like it is. This year Mojang introduced a new compression mode and this might be a good place to switch code for support of multiple compression algorithms. But we might also move the detection into NBT()
You mixed 2 topics in one PR. If have seen that, the changes are fine and reasonable, so everything is ok.
But next time, try to use 2 PRs for 2 topics as then it is easier to distinguish what belongs to what topic.