kona-sp1-proposer: which games should the proposer defend when challenged

Design decision for the defend path (#21463): when the kona-sp1-proposer sees a challenged game, which games is it willing to prove? The prove, resolve, and claim sets must be the same set: a game we would prove is a game we must later resolve and claim. Upstream op-succinct uses option A (it defends any game whose identity matches its own program).

**Which games should our proposer defend (prove) when challenged?**

Option A: every game that runs our program, no matter who created it.
Option B: our own games, plus the games ours are built on.

The case for B:

- Users only depend on our chain of games. A withdrawal goes through when the game covering it resolves in our favor, and those games are the ones we create. If one of ours is challenged, we must prove it. If a game ours are built on is challenged and dies, everything we built on top dies with it. So we defend our games and everything they stand on. That is B.
- A stranger's game outside our chain affects nobody but the stranger. If it dies, our games still cover the same state and users still withdraw. Proving it costs us money and unblocks no user.
- A invites abuse: anyone can create a game with our program and challenge it themselves, and we pay for a proof. We win the challenger bond each round, but the bond is fixed by governance at upgrade time (and by other chains' governance elsewhere), while proving costs move with market prices. Whenever a proof costs more than the bond, we lose money on every round, and we cannot retune the bond quickly.
- B is not a one-way door. If we later want to defend every game of our program, it is a small filter change.

Start by reading defend path issue #21463 and the kona-sp1-proposer entry points, then compare the upstream op-succinct behavior described here. Decide which games belong in the prove, resolve, and claim sets, and document the selected policy and its rationale.

Written by the indexing model from the issue text.