Index global regions by type, identity, name, and chunk

[frostdev-ops]

Experimental motivation

Common global-region lookups repeatedly scan every registered region even when callers ask by type, UUID, name, or a covered chunk.

Scope

GlobalRegionManager maintains derived indexes for type, UUID, name, and covered chunks. Every registry mutation, cleanup pass, and NBT load rebuilds the indexes. Null region types are rejected before registration/indexing. Celestial-object and gravity caches are excluded.

Evidence and limitations

• Java 8 offline Gradle build: passed (test NO-SOURCE).
• Existing fallback scans remain for name/UUID lookup semantics when an index does not produce a matching typed result.
• All pairwise merges and both aggregate build orders passed.
• Lookup parity, lookup latency, and rebuild cost have not yet been benchmarked at multiple registry sizes. This remains draft until those comparisons are recorded.

Manual testing pending

Parity for name, UUID, type, nearest/containment, chat, block-update, cleanup, and NBT reload paths.

[LemADEC]

I've found a couple cases where lags happen, notably if you have hundred if not thousands of celestial objects. Those are already fixed in the main branch. I suggest you rebase your branch and measure where the lag actually happen, then we'll see if there's more that needs to be done on the manager optimisation.

[frostdev-ops]

Rebased onto current MC1.12 (includes 48eb5d9). Honest status: the lag I was chasing was on a heavily modded production world at the same time as the celestial map validation lag you've since fixed, so right now I can't attribute any of it to GlobalRegionManager specifically. I'll profile that world on the rebased build before pushing this further - if getContainers / onBlockUpdating don't show up in spark, I'll close this like #559.

Also aware that if we do keep it, the full rebuildIndexes() on every add/remove/update is O(registry) per update and would need to become incremental first. Leaving as draft until there's data.