What happened: Plain $search / $vectorSearch on timeseries correctly fail with 12093200 / 10557302. The explicit DRM case fails differently:
{$_internalDocumentResultsAndMetadata: {source: {$search: {...}}}}
→ tassert(12615003): 'source' must lite-parse to exactly one stage
Cause: With search-as-extension on, DRM’s parse path desugars the inner $search into multiple stages (extension expand → DRM + idLookup, or similar multi-stage expansion). createFromStageParams then tripwires on innerStages.size() == 1 — before timeseries canRunOnTimeseries can fire.
So timeseries rejection still works for user-facing $search; this case is a host assumption that DRM’s source is always a single lite-parsed stage, which breaks under extension expansion.