Nuker performs a full comparator sort of all found blocks every single tick, really bad design

[hokindo9000]

Describe the bug

In Nuker.java, every tick (onTickPre -> BlockIterator.after callback), the
entire blocks list is re-sorted from scratch using a Comparator lambda,
even in ticks where the block list is identical to the previous tick:

if (sortMode.get() == SortMode.TopDown)
    blocks.sort(Comparator.comparingDouble(value -> -value.getY()));
else if (sortMode.get() != SortMode.None)
    blocks.sort(Comparator.comparingDouble(value -> Utils.squaredDistance(...)));

A new Comparator lambda is also allocated fresh each tick rather than
being cached, adding avoidable garbage collection pressure for a hot path
that runs 20 times per second while the module is active.

For large break ranges (bigger spheres/cubes with many candidate blocks),
this results in a full O(n log n) sort plus repeated distance-squared
calculations every tick, most of which produce the same ordering as the
previous tick if the player and blocks haven't moved much. This adds
avoidable CPU overhead while Nuker is active, especially at larger ranges.

Steps to reproduce

1. Enable Nuker with a large range value and sort-mode set to "Closest"
   or "TopDown" in an area with many breakable blocks (e.g. a superflat
   world or large builds).
2. Profile CPU usage per tick / observe frame time impact while stationary
   with many candidate blocks in range.

Meteor Version

26.1.2-42

Minecraft Version

26.1.2

Operating System

Linux

Before submitting a bug report

• This bug wasn't already reported (I have searched bug reports on GitHub).

• This is a valid bug (I am able to reproduce this on the latest dev build).