Generalize the analysis stack to other games and external conversation corpora

Deferred from the initial scoping of #1, which is D12-only. Filing so we don't lose it.

## Idea

Nothing in the analysis stack is actually specific to Dominating 12. A game reduces to: a map with
a territory adjacency graph, a sequence of board states, a set of players, and timestamped
conversation turns. Any territorial negotiation game fits that shape. If the loaders are written
against that interface rather than against D12's HTML, the same metrics and models run on other
sources for free.

## Why it's worth doing

- **Generalization is the scientific claim.** "Conversations follow stereotyped trajectories as a
function of position strength" is much stronger if it holds in two unrelated games than in one.
A single-site result is always vulnerable to "that's a quirk of D12's player base."
- **Insurance.** If D12 data access is limited in scope or volume, an external corpus keeps the
conversation analysis alive.
- **More board context per message.** Some corpora ship annotations (e.g. intent, deception) that
D12 chat won't have, which lets us validate our unsupervised trajectory findings against labels.

## Candidate sources

- **Diplomacy deception dataset** (Peskov et al., ACL 2020) — real human negotiation in a
territorial conquest game, ~17k messages with board context and per-message truthfulness labels.
Closest available analogue to the D12 setting. Needs a licensing/availability check.
- **WebDiplomacy / Diplomacy engine logs** more broadly
- Other online Risk implementations with public game archives and permissive terms
- Settlers-style trading games, if we want negotiation without territorial conquest as a contrast

## Scope sketch

- Formalize the loader interface implied by #1 (map -> graph, log -> board state sequence,
chat -> turn sequence aligned to board states) as the package's public boundary
- Write a second loader for one external corpus
- Re-run the #1 analyses on it and report where results replicate and where they don't

## Depends on

#1 — the interface has to exist before there's anything to generalize. Ideally #1 is written with
this in mind so the loader boundary is already clean and this issue is mostly additive.

Start by reading issue #1, since this work depends on its loader boundary and analysis stack. Define the public interface for maps, board-state sequences, and aligned conversation turns, then add one external corpus loader and rerun the #1 analyses, reporting which results replicate and which do not.

Written by the indexing model from the issue text.