Optimize Sorting Tree inventory discovery

[KaroUniform]

Summary

• replace the Sorting Tree's cubic block-position scan with iteration over block entities in already-loaded chunks
• preserve the configured inclusive search range, six-sided item capability lookup, and existing input/output behavior
• remove the persistent directional capability cache
• add coverage for chunk boundaries, negative coordinates, unloaded chunks, zero range, and an actual cross-chunk item transfer

Motivation

The previous implementation inspected every block position in the configured cube whenever the Sorting Tree ran. At the default range of 16, that is 35,937 position lookups per activation, and the cost grows cubically with the configured range.

It also retained directional capability caches indefinitely. Those entries were keyed by position and direction without a level, and positions produced by the cube iterator can be mutable, making the long-lived map both unsafe across dimensions and prone to unbounded/corrupted growth.

This change follows the same broad approach as vanilla's Copper Golem: inspect block entities in loaded chunks, then apply the exact configured bounds. It does not load new chunks.

Validation

• ./gradlew cleanTest build — 80 tests passed
• verified transfers across positive and negative chunk boundaries on a NeoForge dedicated server
• completed a 200-tick dedicated-server stress run without item duplication or loss
• manually verified Sorting Tree behavior in a NeoForge client

[jodlodi]

As the idiot that first implemented this iteration of the sorting engine, yeah this looks to be a lot faster and clean. Thank you for taking a look at this