Fix items disappearing when inserted into chests on Fabric

[rubensworks]

Closes #208

Root cause

Fabric's InventoryStorage.of(container, direction) keeps a global Container → storage cache:

private static final Map<Inventory, InventoryStorageImpl> WRAPPERS = new MapMaker().weakValues().makeMap();
// TODO: should have identity semantics?

MapMaker().weakValues() uses equals-based key semantics. CyclopsCore's SimpleInventoryCommon (the base of every chest inventory here) overrides equals/hashCode: two inventories are equal when they have the same size, the same stack limit and the same item types per slot, and hashCode() is a modification counter.

So two chests that are empty and equally sized are "equal" and hash the same, and the second one to be looked up gets handed the first chest's storage. Every insert and every read then goes to the wrong chest, which is exactly what the issue reports: a turtle drops 64 items into a colossal chest core, the items leave the turtle, and never show up in the chest — and reading the chest's item list returns another chest's contents.

Only Fabric is affected. NeoForge and Forge wrap the inventory in a fresh InvWrapper per lookup, with no shared cache.

Fix

Chest inventories are identified by instance instead of by contents, on Fabric only:

• The anonymous inventories of both chests become named classes in loader-common (InventoryColossalChest, InventoryUncolossalChest), and the block entities create them through overridable factory methods.
• loader-fabric subclasses those with identity equals/hashCode, and its blocks and block entity types now create Fabric block entities that use them. Both the block's newBlockEntity and the block entity type's supplier are covered, so a chest keeps its identity-based inventory across a chunk reload. This mirrors how NeoForge already specialises BlockEntityColossalChestNeoForge.

NeoForge and Forge keep using the inventories exactly as they were.

The underlying problem is in SimpleInventoryCommon itself: a mutable, content-based hashCode/equals makes it unusable as a map key for any mod using it. CyclopsMC/CyclopsCore#242 fixes that at the source, which will make this loader-specific workaround redundant once ColossalChests moves off the pinned cyclopscore_version=1.25.3-637.

Three smaller changes come along:

• The ItemStorage.SIDED providers now look up the storage without a direction. These inventories expose all slots to every side and accept everything through every face, so a direction only made Fabric build a fresh sided wrapper — an int[slots] plus one wrapper object per slot — on every lookup. For a chest with tens of thousands of slots that is a lot of garbage per hopper tick.
• UncolossalChest gains a block entity supplier constructor argument, like ColossalChest already had, and with it an instance codec in place of the public static final CODEC. The uncolossal chest's inventory is now created lazily, so the overridable factory is not called from the constructor.
• isFabric() in GameTestsCommon had no callers left after re-enabling the tests below, so it is removed.

One incidental behaviour change: the creative-mode debug inventory (GeneralConfig.creativeChests) now goes through the same factory as the normal one, so it gains the open/close hooks it was missing.

Reproduction and tests

New game test GameTestsFabric#testColossalItemStorageIsPerChest builds two 3×3×3 chests, looks up the second chest's storage first, then inserts 64 apples through the first chest's storage. Without the fix the apples land in the second chest:

gametestsfabric.testcolossalitemstorageisperchest failed! Inserted items did not end up in the targeted chest

The three Fabric hopper game tests that were disabled with "For some unknown reason, this test does not work in Fabric" were failing for this same reason, and are re-enabled. With the fix reverted, testColossalWood5x5HopperInsert fails too; with the fix all 95 game tests pass.

Verified with ./gradlew :loader-fabric:build and ./gradlew :loader-fabric:runGameTestServer against an unmodified CyclopsCore 1.25.3, so the tests exercise this fix and not the CyclopsCore one. The NeoForge and Forge loaders could not be built in this environment (their CyclopsCore and CommonCapabilities artifacts need GitHub Packages credentials); they are untouched by this change beyond the shared plumbing above, and CI covers them.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Wbskd84GPZPE1rB7spHkdn