Fix Fabric fluid sprite reload before Forge texture stitch event dispatch

[yu1745]

The Issue

Fabric's SimpleFluidRenderHandler creates its sprite array before the entries are populated. The entries are initialized later through FluidRenderHandler.reloadTextures(...) during Fabric's fluid renderer reload.

On Forge, TextureStitchEvent.Post can be dispatched before that Fabric reload has run. Forge mods may query Connector's bridged IClientFluidTypeExtensions from this event and receive an array whose still and flowing entries are still null.

BuildCraft exposes this ordering issue by querying the still texture from its TextureStitchEvent.Post listener. Connector then dereferences sprites[0], causing resource loading to fail before the main menu is reached.

Downstream report and stack trace: yu1745/ic2-fabric#18

The Proposal

Reload Fabric fluid render handlers at the head of ForgeHooksClient.onTextureStitchedPost(...), before Forge dispatches TextureStitchEvent.Post to mod event buses.

The implementation:

• only reloads handlers for the block texture atlas;
• deduplicates shared handlers by identity, since still and flowing fluids may use the same handler;
• resolves handlers from FluidRenderHandlerRegistry when they are used, instead of permanently caching a possibly early null result;
• keeps missing-sprite handling as a final fallback;
• returns the default white tint if no render handler is registered;
• logs each missing still/flowing sprite warning only once.

This initializes real Fabric fluid sprites before any Forge mod can query the bridge, while retaining safe behavior for genuinely incomplete fluid render handlers.

Possible Side Effects

Each unique Fabric fluid render handler receives an additional reloadTextures(...) call when the block atlas finishes stitching. This is the lifecycle operation the Fabric API expects for cached fluid sprites.

The reload runs before Forge's post-stitch event subscribers rather than later during Fabric's fluid renderer reload. Handlers are deduplicated, and non-block atlases are ignored.

Invalid or missing handlers now produce a missing texture/default tint instead of crashing resource loading.

Alternatives

Registering a TextureStitchEvent.Post listener with EventPriority.HIGHEST was considered, but Forge dispatches mod-bus events to mod containers in sorted mod order. Listener priority therefore cannot guarantee that Connector runs before another mod such as BuildCraft.

Reloading textures from every still/flowing texture getter was also considered, but that performs lifecycle mutation during ordinary queries and may repeat the reload unnecessarily.

Only returning the missing texture prevents the crash but leaves valid Fabric fluids visually broken and does not address the resource-loading order.

Additional Notes

Base: current 1.20.1 branch at 7411b51ef26b335887810c0c8769187886a54fba.

Validation:

• PUBLISH_RELEASE_TYPE=BETA ./gradlew clean build succeeds.
• Manually tested with Minecraft 1.20.1, Forge 47.4.20, Connector beta49, BuildCraft Lib 7.99.24.9, and IC2 Refabricated.
• The client completes resource loading and reaches the main menu without the original null-sprite crash.