Render each context once per cycle instead of re-reading per visited file

[krlittle]

Summary

• A more targeted alternative to the combination of Stream CsvDataTableStore.getRows from disk lazily instead of buffering the whole table rewrite#7858 + Stream data table rows into context files and render each context once #20, with a much smaller blast radius. It fixes the same redundant-work problem in ExportContext, but as a single-file change in this repo — no change to the shared rewrite-core CsvDataTableStore, and no two-repo release coordination.

• ExportContext renders each context once per cycle and caches the rendered output on its accumulator, so generate() and getVisitor() reuse it instead of re-aggregating the same data tables for every visited context file and again in the forced second export cycle. Reads per table drop from 2 × (F + 2) to 2 (for F context CSVs).

• It does not change how rows are read — each render still materializes the table once via the existing aggregateMatchingTables/exportToCsv path.

• Output is byte-identical.

Problem

ExportContext reads its referenced data tables back to write .moderne/context/*.csv, re-reading and re-rendering each table once in generate(), once for every context CSV visited in getVisitor(), and again in the forced second cycle — roughly 2 × (F + 2) full reads per table (~42× for a repo emitting 19 context CSVs). For large repositories (one row per method/class) that is a lot of redundant decompress/parse/render work per repo.

Why an alternative — and the tradeoff

• Stream CsvDataTableStore.getRows from disk lazily instead of buffering the whole table rewrite#7858 (lazy CsvDataTableStore.getRows) plus Stream data table rows into context files and render each context once #20 (stream rows in ExportContext) together remove the redundant re-reads and the per-render buffering, so a table is never held in memory at any layer. But that combination spans two repos — including a change to the shared rewrite-core store used by every recipe and tool — and the rewrite-core change has to ship before prethink sees the full benefit.

This PR removes only the redundant re-reads (the dominant cost) and stays entirely within rewrite-prethink:

• | | This PR (cache-only) | #7858 + Stream data table rows into context files and render each context once #20 (combined) |
  |---|---|---|
  | Redundant re-reads removed | ✅ ~21× fewer | ✅ ~21× fewer |
  | Per-render table buffering removed | ❌ still buffers once | ✅ streamed; never buffered |
  | Files / repos touched | 1 file, this repo | 2 repos incl. shared rewrite-core |
  | Release coordination | none | rewrite-core must ship first |
  | Blast radius | this recipe only | every CsvDataTableStore consumer |

Opening as a draft to surface the tradeoff for technical review: is avoiding the in-memory buffering worth the two-repo / shared-core change, or is this contained cache-only step the better tradeoff? We'd land one path, not both.

Test plan

• Existing ExportContextTest passes unchanged, including the exact CSV-row + markdown content assertions in aggregatesRowsFromMultipleInstancesOfSameDataTable — confirming byte-identical output
• Adds aggregatesEachReferencedTableExactlyOncePerRun, which installs a counting DataTableStore and asserts each referenced table is read once per export cycle (2 total), not once per visited context file