test: keep the summary content index out of the reply's reach

[Brandon-Tate]

What this covers

A compaction checkpoint is only worth producing if the host can read it back
after the turn. That depends on one thing: the summarize node's run step keeps
the content index it was given. The node builds its own run step and dispatches
it itself, so the graph's index allocation is the only thing standing between
the checkpoint and the assistant's own reply landing on the same slot.

A host that reported a lost checkpoint on an older release saw exactly this
shape: the summary was produced, on_summarize_complete carried a well-formed
block with a boundary, and the saved message contained only the reply text.

Nothing in the suite asserted the guarantee, so nothing would have caught a
regression of it.

The test

src/graphs/__tests__/Graph.summaryContentIndex.test.ts runs a real Run with
FakeChatModel-free recording models and the real createContentAggregator,
then asserts:

• a summarize-only run leaves the summary part on the content the host saves
• a run that also answers keeps the checkpoint and the reply on separate
  indexes, with every dispatched run step on a distinct index

Both cases were verified green on main (v3.9.3), and the whole
src/graphs + src/summarization surface passes with the file added
(18 suites, 287 tests).

Notes

• Test-only change; no source behavior is touched.
• npx eslint, npx tsc --noEmit and sort-imports:check are clean for the
  new file.