Problem

$_internalSearchIdLookup performs shard-local lookups with an equality on _id. On a collection sharded by _id (shard key {_id: 1}), that equality extracts the full shard key, so the shard-side planner omits the shard filtering stage (src/mongo/db/query/query_planner_params.cpp, the "Shards cannot own orphans for the key ranges they own" optimization): it assumes the router has already targeted only owning shards. No router has routed the idLookup's sub-query, so the assumption does not hold, and an orphaned document (e.g. left behind by a chunk migration with suspended range deletion) matches the equality and is reported as found.

Steps to Reproduce

• Shard a collection by _id (shard key {_id: 1}), split it, and move a chunk with range deletion suspended, so the donor shard retains an orphaned copy of a document.
• Run a $_internalSearchIdLookup lookup for that document's _id directly against the donor shard (as the scattered pipeline would).

Expected Behavior

• The orphan is filtered out by shard filtering; the donor-side lookup reports notFound.

Actual Behavior

• The orphan is reported as found.

Notes

• The aggregation engine's local read hits the planner logic above; the SBE engine filters orphans correctly.
• A view-backed lookup forces the aggregation engine and shows the same orphan reporting; that flavor is pinned by the existing viewbacked test in jstests/sharding/query/search/internal_search_id_lookup_ddl_concurrency.js.
• Tests pinning both the non-view aggregation flavor and the confirming non-_id-shard-key view case are added in PR 62347.