Campaign progression: post-victory flow

Part 4 of #22600, depends on #22602. When a campaign mission ends, the player should land on the score screen and then continue the campaign — instead of today's drop into the in-game menu. This is @pchote's step 4, and the one milestone that changes engine behavior.

Design

• Settled constraints (#6122): the flow extends the score-screen dialog — no post-victory play-on, and no bypassing the score screen.
• The victory-conditions code triggers the score screen (win and loss variants per #17067; win/loss FMVs already play today via MissionData) and runs a callback when the player dismisses it.
• The script context must stay callable after game end: the world pauses permanently at EndGame (so Lua Tick and timers stop), but explicit calls into the still-alive context work until the world is disposed. The post-mission choreography must therefore be purely event-chained (dismiss → callback → FMV → callback → …), never delay-based.
• On dismissal, Lua decides what happens next: open the mission-selection screen (milestone 5), load the next mission directly. On defeat: restart / load / exit options per #17067.
• #17057 (the animated TD-style end-mission score screen, closed as stale with a standing "please re-open") is the natural companion for the visuals — this milestone only needs the plumbing, not the polish.

Work items

• Keep the script context alive and callable past game end (today nothing calls into it after EndGame)
• Route mission end into the score screen instead of the in-game menu for campaign missions, win and loss variants
• Surface the dismissal to Lua (e.g. a Trigger.OnGameEnded-style callback or an argument to the score-screen call)
• Wire one reference mission end-to-end: victory → score screen → dismiss → Lua loads the next map

Out of scope

Score-screen visual polish (#17057 can be resurrected separately), the mission-selection screen itself (milestone 5), score aggregation (settled: individual metrics, no arbitrary overall score).