PHAYRIOSIS REBORN CONTINUED — PHASE 7C STARTUP VERIFIER HOTFIX — 0.0.20.1

OBSERVED FAILURE
- 0.0.20 crashed during Forge startup while automatic subscribers were being registered.
- JVM VerifyError reported "Operand stack overflow" in PhaseCalculatorProcedure.execute(Event, LevelAccessor) at the first difficulty-aware requiredPoints() comparison.

ROOT CAUSE
- Phase 7C inserted calls of the form requiredPoints(level, normalThreshold) into pre-existing bytecode.
- The affected PhaseCalculator method still declared the old maximum operand stack size of 4.
- The comparison temporarily requires 5 JVM stack slots: the existing phayriosis_points double (2), the LevelAccessor reference (1), and the threshold double (2).
- The same bytecode-level edit pattern also increased the required stack in PhayriosisMeteorLaunchSystem.forcePhaseFour from 5 to 6, even though startup reached PhaseCalculator first.

FIX
- Recomputed max stack/local metadata for every Phase 7C class that directly references PhayriosisDifficultySystem:
  * PhayriosisDifficultySystem
  * PhayriosisMeteorLaunchSystem
  * BlockspreadspeedconditionProcedure
  * PerennialEvolutionFixProcedure
  * PhaseCalculatorProcedure
  * PhayrileshMoundOnTickUpdateProcedure
- PhaseCalculatorProcedure private execute(...) now declares max stack 5.
- PhayriosisMeteorLaunchSystem.forcePhaseFour(...) now declares max stack 6.
- No gameplay instructions, preset multipliers, thresholds, meteor behavior, UI behavior, or evolution ratios were changed.

VALIDATION
- All six rewritten classes pass an ASM BasicVerifier analysis after repack preparation.
- javap confirms the corrected max-stack declarations.

PERMANENT MAINTENANCE RULE
- Any future bytecode-level insertion that adds method arguments or leaves values on the operand stack must recompute max stack metadata before shipping.
- Do not hand-preserve max_stack from the original method after inserting new calls. Use an ASM writer pass with COMPUTE_MAXS (or compile from maintained source) and verify the final class.
