Investigate caching TypeScript type-table extraction work

[KayleeWilliams]

Context

AutoTypeTable / ExtractedTypeTable conversion can require TypeScript source analysis. Docs pages with several type tables, or many pages pointing at the same source root, may repeat expensive TypeScript program/source-file work.

This is worth investigating separately from the Satteri parser PR because it touches type extraction behavior and cache invalidation boundaries.

Investigation

• Measure type-table extraction cost in conversion benchmarks with fixtures that contain multiple tables.
• Identify repeated work: TypeScript module loading, program creation, source-file reads, symbol/property extraction, or markdown table rendering.
• Explore a per-conversion-run cache keyed by source root, compiler options if relevant, source file path, and extracted type name.
• Preserve strict-mode diagnostics and fallback markdown behavior.

Acceptance criteria

• Benchmark shows whether type-table extraction is a meaningful conversion cost.
• Cache scope avoids stale global state across separate builds/tests.
• If implemented, existing type-table tests pass and generated markdown remains byte-identical for representative fixtures.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}