Guard settings apply without a loaded game

[Sean-Kenneth-Doherty]

Summary

• Guard ApplySettings() when no game is loaded so the settings-applied event cannot dereference HighLogic.CurrentGame from the main menu path reported in issue NRE when changing general settings in the main menu #2.

Why

Issue #2 reports NullReferenceException from MandatoryRCSSettings.ApplySettings() when KSP's settings screen applies changes from the main menu. In that path there is no loaded save, so HighLogic.CurrentGame is null before the method reads custom game parameters.

Validation

• Confirmed issue NRE when changing general settings in the main menu #2's stack points to ApplySettings() through OnGameSettingsApplied() from the main menu settings screen.
• Static source check: every later read in ApplySettings() goes through HighLogic.CurrentGame.Parameters, so returning when HighLogic.CurrentGame is null avoids only the no-save main-menu path.
• Direct source compile with local KSP 1.12.5.3190 managed assemblies using mcs; compile succeeded with two pre-existing unused-field warnings.
• git diff --check HEAD~2..HEAD -- MandatoryRCS-Source/MandatoryRCSSettings.cs

Notes

• This PR is intentionally narrowed to one source change in MandatoryRCSSettings.cs.
• It does not change the packaged DLL, build files, assembly version, AVC metadata, or declared KSP compatibility range.
• I have not run an in-game runtime pass.

[Sean-Kenneth-Doherty]

Closing this under my tightened quality bar rather than leaving an unproven settings-lifecycle draft in your queue. The branch fixes a plausible main-menu settings null path and compiles locally, but the affected in-game/main-menu settings behavior was not runtime-tested in KSP. I will not reopen unless you want this exact fix or there is a concrete player-facing defect with proof.