Replace SEARCH_SORT_LIMIT's ply-indexed leftover-selection budget with

NumLeftoverMovesToSelect, indexed by remaining depth; make EFP's
leftover-only scope explicit.

SEARCH_SORT_LIMIT[ply] was a poor proxy for what actually matters here
-- how large the remaining subtree below this node is. Distance from
root only correlates with that when total search depth is roughly
fixed; it says nothing once extensions/reductions/iterative-deepening
are in play. NumLeftoverMovesToSelect(ctx, uDepth) uses remaining depth
instead, only ever consulted once every high-performer move (winning/
even capture, killer, killer-mate -- anything >= GOOD_MOVE) has already
been exhausted; this never limits how many of *those* get selected,
only how much further care to spend on the ordinary/leftover tail.
Table values carried over verbatim from the old one as an untuned
starting point, just reindexed.

Also adds an explicit (TRUE == fInLeftovers) gate to EFP's per-move
checklist (landed last commit) -- every high-performer move was already
excluded as a side effect of the capture/check/killer exemptions, but
this makes "EFP only ever touches leftovers" a real, direct condition
rather than an emergent property of unrelated checks.

Verified against HEAD (commit bb07fbd) at sd10:
  ecm_ringers:         9/11  -> 10/11 (+1 solve),  ~flat nodes (-0.04%)
  ecm_confident_quick: 88/90 -> 88/90 (even),      +0.43% nodes
  ecm_hard_quick:      15/90 -> 18/90 (+3 solves),  +4.4% nodes
Net +4 solves across 269 positions for a negligible node-count cost.

1 files changed, 53 insertions, 0 deletions

diff --git a/src/searchsup.c b/src/searchsup.c
index 5673bbe..e0d8251 100644
--- a/src/searchsup.c
+++ b/src/searchsup.c
@@ -24,6 +24,59 @@ extern SCORE g_iRootScore[2];
 extern ULONG g_uHardExtendLimit;
 extern ULONG g_uIterateDepth;
 
+ULONG
+NumLeftoverMovesToSelect(IN SEARCHER_THREAD_CONTEXT *ctx, IN ULONG uDepth)
+/**
+
+Routine description:
+
+    How many "leftover" (below GOOD_MOVE -- see search.c's
+    TRY_GENERATED_MOVES gate) moves are worth a full SelectBestWithHistory
+    scan before we give up and just take the remainder in whatever order
+    they're sitting in. Only ever consulted once every high-performer
+    move (winning/even capture, killer, killer-mate) has already been
+    exhausted -- this never limits how many of *those* get selected,
+    only how much further care to spend on the ordinary/leftover tail.
+
+    Replaces the old g_uSearchSortLimits[ply], indexed by distance from
+    the root -- a poor proxy for what actually matters here, which is
+    how large the remaining subtree below this node is (distance from
+    root only correlates with that when total search depth is roughly
+    fixed; it says nothing once extensions/reductions/iterative-deepening
+    are in play). uDepth (remaining depth, in ONE_PLY units, possibly
+    fractional) is the more principled signal: a bigger remaining
+    subtree makes the cost of a few extra O(n) selection scans more
+    worth paying to avoid a bad early choice cascading into extra
+    full-width re-searches.
+
+    STARTING POINT, NOT YET VALIDATED under this new meaning: this
+    reuses the previous table's six numbers verbatim, just reindexed by
+    plies of *remaining* depth instead of *distance from root* -- same
+    overall shape (more care with more depth left), same specific
+    values, carried over only because they're a known, testable
+    starting point, not because they were ever confirmed correct here.
+
+Parameters:
+
+    IN SEARCHER_THREAD_CONTEXT *ctx,
+    IN ULONG uDepth
+
+Return value:
+
+    ULONG
+
+**/
+{
+    static const ULONG _uLimits[] = { 8, 9, 11, 13, 15, 17 };
+    ULONG uPlies = uDepth / ONE_PLY;
+
+    if (uPlies >= ARRAY_LENGTH(_uLimits))
+    {
+        uPlies = ARRAY_LENGTH(_uLimits) - 1;
+    }
+    return(_uLimits[uPlies]);
+}
+
 void
 UpdatePV(SEARCHER_THREAD_CONTEXT *ctx, MOVE mv)
 /**