Fix for plane confusion in block sorting due to bad blocks

[jcan]

During flash data recovery, we often encounter plane disorder issues caused by bad blocks.
For example, blocks that originally belong to Plane 0 will be misplaced to the position of Plane 1.See the figure below:

Synchronize in groups of four blocks with a step value of 1.The correct final LPN sequence for each group of four blocks should be 0, 1, 2, 3.
As shown here, selecting 0x1AC reveals a conflicting block with an LPN value of 0x03.This block should be the last one within the current four-block group starting at LBN = 0x6B.However, in the actual dump, the block LBN=0x6B / LPN=0x03 is misplaced into Plane 0, resulting in poor reconstruction results with the original compilation method.
Although NFT supports manual block number modification, manual adjustment is extremely time‑consuming when large numbers of such errors occur.
Traditional modification method:Manually correct the block sorting order.

This wastes a great deal of the user’s time.
NFT has added the LPN to Plane function:

The sorting result after enabling this option is as follows:

We can see that the correct result can be obtained directly without manual modification.

[csava]

practical feature theoretically applicable to all controllers with block sorting and LPN