as part of the migration of $search to SBE, we will be using DocumentSourceCursor together with PlanExecutorSBE. Due to how DocumentSourceCursor batching works, there is a potential risk that the performance of some queries will significantly degrade. Specifically queries like:
{{[$search, $stageNotSupportedBySBE, $unwind, $limit] }}  will result in DocumentSourceCursor attempting to unnecessarily populate potentially a large batch of documents (4MB), which could potentially take multiple roundtrips to mongot, and then $limit may discard majority of that.This issue will not appear for "nicer" queries like:
{{[$search, $stagesSupportedBySBE..., $limit] }}  -> here $limit will be pushed down below DocumentSourceCursor and the application of $limit will be done eficiently.
[$search, $stageNotSupportedBySBEButReorderableWithSkipLimit..., $limit]  -> here despite $limit being outside of supported prefix, the $search stages will infer the limit and apply it properly (at least after https://jira.mongodb.org/browse/SERVER-78351 is fixed).This problem should go away once SBE supports all stages, however until then there is a risk that some queries may become really really slow. Is this a blocker for shipping the search on SBE?

Use exponential batch size growth in DocumentSourceCursor to avoid performance issue for particular queries in SBE.