Register config properties in the spec of their location

[rubensworks]

Problem

ConfigHandlerNeoForge, ConfigHandlerForge and ConfigHandlerFabricHandler create a spec builder per ModConfigLocation, but then pass the COMMON builder to onConfigPropertyInit for every property. As a result:

• Every @ConfigurablePropertyCommon ends up in the common config file (-local.toml on NeoForge 26), whatever its configLocation.
• The CLIENT and SERVER specs are registered but empty.
• SERVER properties are therefore never per world or synced to clients, and CLIENT properties aren't client-only.

This goes back to before the multiloader port (configProperty.onConfigInit(configBuilder) in the old ConfigHandler).

Fix

• initialize passes the property's own builder (configBuilderProperty) to onConfigPropertyInit.
• syncProcessedConfigs only writes back properties whose location matches the type of the config being loaded or reloaded. Without this, loading the common config would read values from a CLIENT or SERVER spec that isn't loaded yet, which throws. On Fabric this changes syncProcessedConfigs(boolean) to syncProcessedConfigs(ModConfig, boolean), matching the other loaders.
• A TODO on ModConfigLocation to rename COMMON and SERVER in the next major, to match NeoForge's LOCAL and SYNCED (what modConfigLocationToType already maps them to).

Breaking change

On master-26 only, as discussed. Values players customized in the common file for properties marked CLIENT or SERVER are no longer read. Those properties start from their defaults in their new file (client config, or the synced/server config). Server admins and pack makers who changed such options need to set them again.

Validation

• ./gradlew build passes.
• ./gradlew runGameTestServer: "All 4 required tests passed" on NeoForge, Forge and Fabric, before and after the change.
• I checked the generated config files with an A/B run: I deleted the run configs, ran the game test server on unmodified master-26, then again with this change. Cyclops Core's own GeneralConfig has two CLIENT properties (devWorldButton, devDisableMusic):
  • Before: both are written to cyclopscore-common.toml (Fabric, Forge) and cyclopscore-local.toml (NeoForge).
  • After: they're only in cyclopscore-client.toml. Fabric writes it even on a dedicated server; NeoForge and Forge don't create a client config on a dedicated server. No Cyclops Core config file is written on the server for NeoForge and Forge, since Cyclops Core has no COMMON or SERVER properties of its own.
• I didn't add an automated test. initialize needs a live mod container and registers configs globally, so testing it needs a refactor I'd rather not mix into this fix.

Not included

minimalValue / maximalValue from the annotation aren't enforced: properties use define rather than defineInRange. That's a separate change, which could also land on master-26 if wanted.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSz5r6eowhjNuANBjZE2v6

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate failed

Failed conditions
70.0% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[coveralls]

coverage: 31.457% (-0.09%) from 31.544% — fix-config-locations into master-26