PHAYRIOSIS WORLD SETTINGS - PHASE 2

Purpose
Create a safe, versioned, per-world configuration authority before building the Create World GUI or meteor event.

New backend
Class: net.mcreator.phayriosisreborn.config.PhayriosisWorldSettings
SavedData name: phayriosisreborn_world_settings
Schema: 1

Legacy settings represented
- blockSpreadEnabled
- playerConversionEnabled
- conversionsEnabled
- phaseFreezeEnabled
- parasiteSpawningEnabled
- dimensionalSpawningEnabled
- nightmareModeEnabled
- maxInfectableHardness
- blockSpreadSpeed

Dormant meteor schema fields
- meteorEnabled
- meteorMinimumDay
- meteorMinimumPhase
- meteorCheckIntervalTicks
- meteorChance
- meteorMinDistance
- meteorMaxDistance
- meteorSizeScale
- meteorFragmentsEnabled
- meteorInfectionEnabled

IMPORTANT: meteor fields are persistence placeholders only in Phase 2. No meteor scheduler, entity, crater, worldgen disable, or infection impact code reads them yet. Do not claim meteor behavior changed in this build.

Compatibility bridge
- EventBusVariableHandlers.onPlayerLoggedIn calls PhayriosisWorldSettings.ensureInitialized(level).
- Until worldCreationConfigured becomes true, ensureInitialized/mirrorLegacy copies the current legacy MapVariables settings into the new backend and marks it dirty.
- CommandmaxhardnesssetProcedure and CommandblockspreadspeedsetProcedure call mirrorLegacy before returning, keeping the two exposed admin commands synchronized immediately.
- Existing gameplay continues to read legacy MapVariables in Phase 2. This is intentional to make the migration behavior-neutral.

Future handoff
When the Create World settings UI is implemented:
1. Collect a client-side draft before world creation.
2. Persist that draft into PhayriosisWorldSettings when the integrated server creates/loads the new world.
3. Set worldCreationConfigured=true.
4. Mirror selected values back to legacy MapVariables temporarily while existing procedures are migrated.
5. Migrate gameplay readers gradually to PhayriosisWorldSettings, then delete the compatibility bridge.

Verifier/build safety
- Phase 1 demonstrated that raw NOP bytecode patches can invalidate StackMapTable frames on Java 17.
- Phase 2 uses verifier-safe compiled bytecode for the new class and ASM instruction insertion that preserves/re-emits existing frames; do not return to direct opcode overwrites.
