Use the security sector's disk size when calculating the size of the data partition

[InvoxiPlayGames]

This restricts the number of sectors used for the data partition to what the MS security sector says.

This matches the behaviour of the official, unpatched OS. There is a problem here, though...
If a drive has a legitimate security sector, and the drive's true ending LBA is greater than what is specified, (e.g. a larger SSD that has been flashed with a fake model/serial, and a real drive's secruity sector written to it), then pre-September 2026 xebuild patches (patched in J-Runner with Extras V3.4.0 r6) and libxtaf (before this PR) will see a completely different FAT from the drive compared to retail consoles, or newer hacked NAND images.

We're going to assume that, since if a security sector exists you want to use the drive on a retail console, that we should read the partition as if it is a retail console and use the same XTAF extents. There are no good solutions here, but I think using the retail OS behaviour is the most well-intentioned solution.

---

Testing is sorely needed to make sure that files are being read from the "correct" view of the XTAF filesystem so we aren't reading a possibly garbage FAT.

Expected behaviour:

• Fully official Microsoft drives, or flashed HDDs of identical LBA count, behave the exact same.
• Fully unofficial drives (no security sector) behave the exact same.
• On an unofficial drive with a security sector where the disk's LBA count exceeds the security sector's stated size, the FAT is read as if the partition ends where the security sector says it ends.