feat: wire NeoForge runtime support

[AdolfoCarneiro]

Summary

This wires the NeoForge runtime path end-to-end so the mod actually initializes, renders, ticks, and interacts on
NeoForge.

The original issue listed this as several small implementation areas, but the work ended up needing to be validated
as an integrated runtime path because bootstrap order, capabilities, networking, ticking, client rendering, and model
loading all depend on each other. I opened this as the integration PR so the full NeoForge behavior can be reviewed
and tested together.

PR size note

The issue originally suggested doing this as several small PRs. I started from that direction, but the NeoForge
runtime path ended up needing end-to-end validation because the pieces are tightly coupled:

• bootstrap has to happen before registries and capabilities are usable
• capabilities need the common SPI and storage adapters
• packet registration depends on common networking contracts
• ticking/lifecycle events depend on initialized pipe/quarry/cable systems
• client rendering depends on shared model registration and NeoForge model loader wiring

Because of that, this branch became the integrated implementation pass that I tested heavily in-game.

If you prefer this split into smaller review chunks, I can break it into stacked PRs in roughly this order:

1. Bootstrap, SPI implementations, and ServiceLoader smoke tests
2. Energy/item/fluid capability adapters and lookup wiring
3. Networking, lifecycle events, commands, loot, and creative tab wiring
4. NeoForge client rendering, model loading, and shared client renderer moves
5. Documentation, build cleanup, and generated artifact ignores

I opened this as a draft/integration PR first so the full working state is visible and testable before deciding
whether splitting is worth the extra churn.

What changed

• Initialized common domain bootstrap from the NeoForge mod entrypoint.
• Added NeoForge implementations for the loader SPIs:
  • BlockEntityTypeFactory
  • PlatformService
  • CreativeTabRegistrar
  • ResourceReloadRegistrar
  • EnergyCapabilityLookup
  • FuelHelper
• Wired NeoForge capability registration for:
  • energy
  • item storage
  • fluid storage path
  • pipe connections
• Added NeoForge adapters for common storage abstractions:
  • energy
  • items
  • fluids
  • item/fluid keys
• Wired NeoForge networking for serverbound and clientbound logistics packets.
• Wired server lifecycle events for pipe/cable ticking and quarry/network cleanup.
• Wired commands, chest loot injection, creative tab population, registry aliases, and biome modifiers.
• Added NeoForge client setup for screens, engine renderers, pipe renderers, quarry/marker renderers, block colors,
  cable models, and standalone model loading.
• Moved reusable vanilla client renderers/models into common/src/client so Fabric and NeoForge share the same
  visual implementation.
• Updated AGENTS.md and CLAUDE.md with the current multiloader architecture rules and the patterns used here.
• Ignored generated local run/build artifacts.

In-game validation

I did a lot of manual in-game testing on NeoForge after this work.

Validated areas included:

• Mod launches on NeoForge without crashing.
• Blocks and items appear in creative tabs.
• Energy behavior works in-game.
• Engines push energy to adjacent compatible blocks.
• Cables tick and transfer energy.
• Pipes are visible and render correctly.
• Pipe item routing works through a basic network.
• Quarry visual pieces render correctly, including the drill/arm path.
• Quarry runtime behavior works during testing.
• Client screens/network packets used during pipe interaction work.

A visual issue found during testing, where pipes and the quarry drill were invisible on NeoForge, was fixed by
sharing the existing Fabric-tested renderers through common/src/client and wiring the NeoForge model/BER
registration correctly.

Architecture notes

I audited the branch against the repo guidance after testing.

Important constraints preserved:

• common/src/main remains loader-agnostic.
• common/src/client uses vanilla client APIs only, no Fabric or NeoForge imports.
• Loader-specific APIs stay in fabric/ or neoforge/.
• NeoForge client-only handling stays under com.logistics.neoforge.client.
• NeoForge clientbound payload handlers are registered through RegisterClientPayloadHandlersEvent, so common
  NeoForge packet registration does not import client classes.
• Capability wrappers preserve the common storage contracts and adapt to NeoForge transaction semantics instead of
  changing shared code around NeoForge.

Fabric build still passes, including the existing gametest suite.