perf(search): persist search sections in content.cache instead of a WeakMap

[atinux]

Summary

The search index (one section per heading, built by parsing every document) was memoized in an in-process WeakMap keyed by the ComarkContent instance. On serverless, that means every cold start / new lambda instance rebuilds the whole index: content.list + content.get for every doc (GitHub fetch + parse).

This replaces the WeakMap with content.cache under a reserved search-sections key. The cache driver is the Vercel Runtime Cache namespaced per SHA (content:${sha}), so:

• the index survives cold starts and is shared across lambda instances in the region
• invalidation stays free in prod/preview: a new head or preview SHA reads from a fresh namespace
• dev invalidation keeps working: the watch:file:update/remove hooks now call cache.invalidate (memory driver in dev)

Notes

• The key is colon-free so it can't collide with <source>:<path> content keys, the manifest key, or the shared gh: namespace, and the SWR fallback in cache.get can't map it to a real source.
• cache.set failures are non-fatal (covers the Runtime Cache per-item size limit) — an oversized payload just means no persistence.
• Trade-off, discussed beforehand: no more in-flight dedup, so concurrent requests on a cold instance can each build the index once. Accepted since this backs a client-side search API route.

Verification

Ran pnpm typecheck, pnpm lint (only pre-existing warnings), and pnpm test (110 tests pass).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
comark-docs-playground	Ready	Preview	Aug 6, 2026 1:02pm

[pkg-pr-new]

npm i https://pkg.pr.new/comarkdown/comark-docs@12

commit: 42e6dd5