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.

0 files changed, 0 insertions, 0 deletions