Fix: base .aslx file's own duplicate template names lose to the first, not the last

[alexwarren]

Summary

• Loading a bare .aslx (not a compiled .quest package — e.g. WasmPlayer's ?id= route, which fetches an unpacked .aslx via the textadventures.co.uk API instead of a .quest zip) runs GameLoader.ScanForTemplates, a preliminary pass that locks in the first value seen for each template name as an unoverridable "base template", so a later library file can't clobber a game's own override.
• Old Quest 5.8 desktop exports inline a full language pack directly in the base file instead of as a separate library (e.g. an English block followed by a German block, both defining the same template names). The guard was blocking the later, correct definition from winning even though both come from the base file itself — silently keeping the earlier English text (e.g. You are carrying instead of Du trägst).
• Template.AddTemplate's guard now only blocks a non-base (library) definition from overwriting a locked base template — a later base-template definition (still within the same base-file scan) is allowed to win, matching ordinary top-to-bottom XML semantics. This doesn't change the original protection (a library trying to override a game-defined template is still blocked).

Test plan

• Added tests/EngineTests/duplicatetemplatetest.aslx, a minimal bare .aslx fixture (no <include>d libraries) defining the same template name twice.
• Added TemplateTests.DuplicateTemplateInBaseAslxFile_LaterDefinitionWins, which loads that fixture and asserts the later definition wins.
• Verified the new test fails against the pre-fix code (Expected: German value. Actual: English value) and passes with the fix.
• Full EngineTests suite passes (273/273).
• Reproduced the original bug end-to-end against a real reported game file by serving its raw .aslx the same way WasmPlayer's ?id= route does, confirmed the fix resolves it there too.

🤖 Generated with Claude Code