Timestamp do not need to be accurate order as the requirements for a block ordering must be the block height, as such the timestamp can for a previous block can be lower than that of a higher a block because the timestamp rules is that it needs to be in the median of the time stamp of the last 11 blocks according to bitcoin wiki. The time stamp is just used to calculate the difficulty and not necessarily the block order.

In this case it might be that the mempool.space node received the block 826743 before the block 826742 because there is no way that the block 826743 would have been mined before the 826742 because the latter needs the block header of the former. The real mined time isn’t classified by the timestamp

The time stated is the timestamp of the block and not the received time. As you have identified, the block timestamp doesn’t have to be sequential. Hence, it would be perfectly fine for the timestamp of a future block to come before the timestamp of an earlier block so long as it fulfils the Median Past Time.

Pools would usually try to broadcast the block immediately, or with minimal delay and propagation should he under a minute as well.

It would probably create too many forks, each node has a different range of acceptable time when considering the network adjusted time. Each node would also see a different set of valid blocks.