perf(www): cache and parallelize registry source loading

[Yeom-JinHo]

Description

This PR reduces server-side work when rendering docs pages and LLM markdown that include registry component sources.

It caches registry source loading, removes redundant per-call processing, and parallelizes ComponentSource replacement so docs-related routes do less file I/O and less serial async work.

Changes

• Cache registry item and file content loading with React.cache()
• Normalize registry file entries once before validation/loading
• Remove unnecessary per-request ts-morph/temp-file setup from registry source extraction
• Parallelize <ComponentSource /> replacement in docs content instead of resolving each item sequentially
• Keep existing output behavior the same while making docs/LLM source generation lighter
• Preserve fail-fast registry validation while caching and parallelizing source loading

Motivation

Docs pages and the LLM route repeatedly read the same registry source files, and the previous flow did extra work on every call.

This change is intended to improve response time and reduce unnecessary server I/O for docs pages that render component source blocks.

Breaking Changes

None.

[vercel]

@Yeom-JinHo is attempting to deploy a commit to the product-studio Team on Vercel.

A member of the Team first needs to authorize it.

[Yeom-JinHo]

Benchmark Results

Local benchmarks show consistent improvements across both route-style and server-rendered docs workloads.

Environment:

• Node v22.17.1
• Base: db541666
• PR head: df109a24

Measured improvements:

• route_single_magic_card: 84.99% faster
• route_two_tag_tweet_card: 87.07% faster
• route_all_docs_combined: 95.67% faster
• route_synthetic_20_components: 93.65% faster
• render_single_magic_card_page: 79.10% faster
• render_all_docs_pages: 85.35% faster

This validates that the change meaningfully reduces docs/LLM source-processing cost, especially for pages that resolve multiple <ComponentSource /> blocks.