Problem
The jstest fails when Classic multi-planner for SBE is enabled. It fails at the line 240:

assertQueryParameterizedCorrectly({
    query: {a: {$eq: 1}, b: {$in: maxExplodeIn}},
    queryCount: 6,
    newQuery: {a: {$eq: 2}, b: {$in: maxExplodeIn}},
    newQueryCount: 12,
    reuseEntry: true,
});

Reproduce

ninja -j128 install-devcore build/install/bin/db_query_test && buildscripts/resmoke.py run --suite core --mongodSetParameters='{logComponentVerbosity: {query: 5}}' --additionalFeatureFlags featureFlagSbeFull,featureFlagClassicRuntimePlanningForSbe jstests/core/query/explode_for_sort_plan_cache.js

Investigation
The root cause is due to the difference in how keysExamined and numRead tracked in SBE, leading to different criteria for replanning such that Classic decides not to replan whereas SBE decides to replan.
1. Classic only increment keysExamined for examining key.
2. SBE increments numRead for both examining and seeking.

Tracing down the callback, it appears that the query is `isExplainAndCacheIneligible() = true`, such that
1. isExplainAndCacheIneligible returns true
2. shouldCacheQuery returns false
3. shouldUpdatePlanCache return false
4. updateSbePlanCacheFromClassicCandidates stops caching the plan.

Question
1. It doesn't seem obvious how such query is explain.
2. Why the other queries work as usual? Commenting how this test case in line 240 will make the rest of test pass successfully.
1. Because the number of seeks are small enough for CRP_SBE not to replan in the rest of examples.