Can Storybook's stories.json manifest be paginated or lazily loaded for libraries exceeding 10k stories?

Context

Storybook 7+ emits a single stories.json index at build time containing every CSF story as a flat array. The sidebar virtualizes rendering via react-window, yet the entire manifest is downloaded and parsed before any UI appears. For component libraries with >10k stories this creates multi-megabyte payloads and noticeable parse delays on cold loads.

Constraints

• The Indexer API (@storybook/types) allows filtering at build time but exposes no page, limit, or cursor fields for incremental emission.
• loadStories enables on-demand imports in development, but production builds always embed the complete index; no documented hybrid mode exists.
• Sharding into multiple Storybook instances or custom indexers breaks deep-linking and global search unless a custom resolver is added.

Open questions

1. Does the core team have a planned API shape for manifest pagination or incremental index generation?
2. Can a custom indexer emit sharded indexes that the standard sidebar can consume without forking @storybook/components?
3. What is the recommended pattern today for a 15k-story library that must keep initial load under 200 KB?