Problem

A tripwire assertion can be reached (Location13248900) when a $graphLookup sub-pipeline containing $_internalFromPipeline and sends it to another shard that has featureFlagExtensionsInsideHybridSearch disabled.

Root cause

Serialization/parsing asymmetry in DocumentSourceGraphLookUp:

• Serialization does not check featureFlagExtensionsInsideHybridSearch (document_source_graph_lookup.cpp:255-266) emits $_internalFromPipeline whenever _params.fromLpp has non-empty stages and we are serializing for remote.
• Parsing (document_source_graph_lookup.cpp:72-78) routes to createFromBson() when the flag is disabled, and createFromBson() tasserts (13248900) if $_internalFromPipeline is present (document_source_graph_lookup.cpp:513).

The tassert's comment assumes this combination is impossible: a shard that disables the flag mid-operation propagates an IFRFlagRetry to the router, which retries with the flag off and does not serialize $_internalFromPipeline at all. That assumption breaks in the multiversion case: an 8.0 mongos sends no ifrFlags, so 9.0 shards install the flag as false (installForRequestWithoutIfrFlags sets every flag introduced since last-LTS to false). A 9.0 shard acting as sub-router still resolves the involved views (populating _params.fromLpp with non-empty pipelines) and serializes $_internalFromPipeline regardless of its own flag state, so the flag-disabled receiving shard hits the tassert.

Suggested fix

Gate the serialization of $_internalFromPipeline by the flag in DocumentSourceGraphLookUp::serialize(), so a flag-disabled sender never emits it and a flag-disabled receiver never parses it. The legacy view-resolution path (makePipeline() retry loop) resolves the view on the receiving shard instead.