Use the surviving CGS code for Escorpion Imperio diplomacy data

[HammerGS]

What this fixes

In any campaign from 3080 onward, Clan Goliath Scorpion was about twice as likely as it should be to
come up as a contract employer, and the Hanseatic Crusade was declared twice over as a war.

Both come from the same cause: this data still used CEI, the retired faction code for the Escorpion
Imperio.

Why the old code is a problem

The Escorpion Imperio (CEI) and Scorpion Empire (SE) faction files were consolidated into CGS.
That one file now covers the whole lineage, and renders as "Escorpion Imperio" from 3080 and "Scorpion
Empire" from 3141 through its nameChanges. CEI survives only as an alias, so that old campaign
saves and other data we cannot go back and edit keep resolving to the surviving faction. It is a
compatibility shim, not a spelling we should still be writing into current data.

Once you read CEI as meaning CGS, two of these entries stop making sense:

Goliath Scorpion contained inside itself. The file said the Escorpion Imperio has Clan Goliath
Scorpion living inside its borders. That was true when they were two separate factions - but they are
one faction now, so the line reads "Goliath Scorpion contained within Goliath Scorpion". Contract
generation counts each faction once for itself, then again for every faction living inside it, so CGS
got counted twice and its odds of being drawn as an employer roughly doubled.

The same war, twice. The Hanseatic Crusade listed both CEI,HL and CGS,HL as warring parties.
Those are now the same two factions, declared at war with each other in duplicate.

Changes

• Removed the CEI contains CGS entry. After the consolidation the Goliath Scorpions are the host
  here, not something contained within the host.
• Removed the duplicate CEI,HL war party line from the Hanseatic Crusade.
• The three genuine containments - Nueva Castile, the Umayyad Caliphate and the Hanseatic League inside
  Scorpion space - now name CGS as the host and keep their existing fractions (0.3, 0.3 and 0.5).
• Added comments recording why the host is CGS and why there is deliberately no CGS-inside-CGS entry,
  so this does not get "helpfully" restored later.

The legacy factionhints.xml gets the identical changes. That part is not optional: MekHQ compares the
legacy XML against the factionDiplomacy YAML to detect a player's customised XML, so if the two drifted
apart every player would be told their factionhints.xml had been customised when it had not.

Files Changed

• data/universe/factionDiplomacy/3080-present_escorpionImperio.yml
• data/universe/factionDiplomacy/3141-3142_hanseaticCrusade.yml
• data/universe/factionhints.xml

Testing

• factionhints.xml still parses as well-formed XML; both edited YAML files still parse.
• Verified no live CEI reference remains anywhere in the diplomacy data - the only remaining mentions
  are the explanatory comments.
• Verified the XML and the YAML still express the same set of relationships, which is what the
  legacy-XML comparison checks.

Playtested in MekHQ with this data staged. The diplomacy data loads with no faction errors:

[FactionDiplomacy] Loading faction diplomacy data from data\universe\factionDiplomacy
[FactionDiplomacy] Loaded 94 files from data\universe\factionDiplomacy (0 failed)

Two things that matters:

1. The Invalid faction code ... CEI errors are gone from logs/mekhq.log, in both the
   factionhints.xml form and the [FactionDiplomacy] ... in 3080-present_escorpionImperio.yml form.
2. No "customised legacy XML" warning was raised, which is the runtime check that the XML and the
   YAML still agree. That was the riskiest part of this change - had only the YAML been updated, the two
   would have drifted and every player would have been wrongly told their factionhints.xml had been
   customised. They still match.

What is NOT proven yet

• The doubled employer weighting was never measured. It was traced by reading
  RandomFactionGenerator - it merges a weight for the faction, then again for each faction contained
  within it - not by comparing contract generation before and after. The reasoning is solid, but
  confirming the 2x effect would need many contract draws and a tally, so the fix is verified while
  the original magnitude is not.
• The playtest does not separate this change from Resolve retired faction codes through their aliases (CEI, SE) mekhq#9739, which was applied at the same
  time; either one alone would have silenced the log errors. The parity result above, however, is
  specific to this PR.
• Only a new campaign was exercised. Existing saves referencing the old codes were not loaded.
• Related, but independent of this PR: MekHQ's Factions.getFaction() does not resolve faction aliases
  at all, so retired codes in other places - campaign saves, planetary ownership, RAT availability
  tables - still fall through to the placeholder faction. That is fixed separately in
  Resolve retired faction codes through their aliases (CEI, SE) mekhq#9739. The two can merge in either order and neither blocks the other.