snatchAndLoad logs ERROR on a benign snatch-miss — please demote (or return a boolean)

[bh679]

Version: sable 2.0.2+mc1.21.1 (NeoForge 1.21.1)

SubLevelHoldingChunkMap.snatchAndLoad(pointer, uuid) logs at ERROR whenever SubLevelHoldingChunk.snatch(uuid) returns null (the chunk exists but its loadedHoldingSubLevels map has no entry for that UUID):

Attempted to snatch sub-level with ID {} stored at {}, but the requested sub-level wasn't present in the holding chunk

Why this is a benign, expected outcome for some callers

A held sub-level can legitimately be present in the global allHoldingSubLevels map (what getHoldingSubLevel(uuid) reads) while already absent from its chunk's loadedHoldingSubLevels map. A caller that decides whether to reload from getHoldingSubLevel(uuid) != null and then calls snatchAndLoad will hit this path — the snatch simply finds nothing to do. It is not corruption or a lost sub-level; snatchAndLoad correctly returns without loading.

But because it is logged at ERROR with no way for the caller to detect the miss beforehand, a caller that polls holding state each tick produces a large volume of alarming ERROR lines (~2855 identical lines in a 20-minute session in our case) for a completely harmless condition.

Request (either would resolve it)

1. Demote to DEBUG (or WARN) — a snatch-miss is a normal outcome, not an error; or
2. Return a boolean from snatchAndLoad (true = loaded, false = nothing snatched) so callers can detect the miss and log at their own discretion instead of Sable logging ERROR unconditionally.

The same applies to the sibling "…but no holding chunk was present at the pointer chunk position" branch in the same method.

Happy to open a PR if a direction is preferred. Thanks for Sable — the holding / sub-level system is great to build on.