bugfix(loadscreen): Prevent null dereference in ChallengeLoadScreen::init from invalid campaign/mission

[seer-by-sentry]

This PR addresses issue CLIENT-33Q, where the game would crash in AsciiString::AsciiString during ChallengeLoadScreen::init.

Root Cause:
The ChallengeLoadScreen::init function (Core/GameEngine/Source/GameClient/GUI/LoadScreen.cpp:930) would attempt to dereference campaign->m_name and mission->m_generalName without proper null checks. While DEBUG_ASSERTCRASH was present, it is compiled out in release builds, allowing null pointers returned by TheCampaignManager->getCurrentCampaign() or TheCampaignManager->getCurrentMission() to proceed. This led to an EXCEPTION_ACCESS_VIOLATION_READ when the AsciiString copy constructor tried to read from invalid memory (offset 0xa0).

This scenario typically occurred when GameLogic::startNewGame was invoked via logicMessageDispatcher with an uninitialised or stale campaign state.

Solution:

1. Added comprehensive null checks for TheCampaignManager, campaign, and mission at the beginning of ChallengeLoadScreen::init. If any are null, the function now logs a DEBUG_CRASH message (visible in release builds) and returns early, preventing the dereference.
2. Validated mission->m_generalName to ensure it's not empty before use.
3. Added null checks for TheChallengeGenerals and the generalPlayer/generalOpponent pointers returned by its lookup functions.
4. Replaced a redundant call to TheCampaignManager->getCurrentMission() on line 956 with the already validated mission local, ensuring consistency and preventing another potential null dereference.

These changes ensure that ChallengeLoadScreen::init gracefully handles cases where campaign or mission data is not properly set up, preventing crashes in release builds.

Fixes CLIENT-33Q