Remove dead EFP references left over from its removal

EFP (extended futility pruning) was removed from Search()'s move loop
in favor of LMP's joint FH% table, but several comments, a dead
counter (u64EFPPruned, never incremented anywhere), and two unused
defines (EFP_FH_MIN_SAMPLES/EFP_FH_PRUNE_THRESHOLD_PCT_THOUSANDTHS)
were left behind claiming EFP still gates something. Clean these up:

- Delete u64EFPPruned (COUNTERS and g_Options) and its dead
  reader/writer in root.c.
- Delete the two unused EFP_FH_* defines in search.c, and the stale
  fAnyMoveEFPPruned comment describing a branch that no longer
  skips a store.
- Fix dangling prose references to EFP in generate.c, chess.h,
  searchsup.c, and testsearch.c that describe present-tense behavior
  EFP no longer participates in, preserving the historical rationale
  where it's still relevant (e.g. why EstimateHangingMaterialCp can
  return a negative value).

Deliberately left alone (flagged for a separate decision, not a
clear delete): script.c's still-live JOINT_EXTRA_VERIFY calibration
labels ("EFP tier1/tier2"), search.c's _PostReduceDepthBucketEfpAligned
(same live mechanism, name only), searchsup.c's LMP_BASE_MOVENUM/
LMP_PER_PLY_MOVENUM dead macros (kept pending a real floor/ceiling
decision), and PLY_INFO.iPositional[2] (now write-only, but removing
it touches Eval()'s call signature everywhere).

Comment/dead-code only, no logic touched.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

1 files changed, 13 insertions, 11 deletions

diff --git a/src/searchsup.c b/src/searchsup.c
index a048d39..d94dbb4 100644
--- a/src/searchsup.c
+++ b/src/searchsup.c
@@ -281,9 +281,11 @@ Return value:
         sign in that case rather than clamping it away -- IID's shallow
         search genuinely knows more than a static material exchange
         does, and a caller folding this value directly into a margin
-        calculation (EFP, search.c) WANTS "this move turned out to
-        actually be good" to look like the opposite of "hung", not like
-        "hung = 0" -- see search.c's EFP comment. Callers that need a
+        calculation WANTS "this move turned out to actually be good" to
+        look like the opposite of "hung", not like "hung = 0" (this
+        historically mattered for EFP's margin check, search.c, now
+        removed -- the reasoning is preserved here in case a future
+        direct-margin consumer reappears). Callers that need a
         true cp-loss-or-zero reading instead (the "dumb" axis feeding
         the joint FH table) must go through HangCpBucket, which clamps
         exactly this case to bucket 0 rather than asserting it away.
@@ -795,8 +797,8 @@ Routine description:
     2026-10-04: hoisted out of Search()'s move loop (search.c), where
     this had grown into an inline block setting fPruneReduceEligible
     plus two more exemption checks (killer-adjacency, countermove
-    match) immediately below it -- EFP, LMP and LMR all gate on the
-    combined result. Pulled into one function so the "is this move
+    match) immediately below it -- EFP (since removed), LMP and LMR all
+    gated on the combined result. Pulled into one function so the "is this move
     even a candidate for pruning/reduction" question has a single,
     named answer instead of three co-located but separately-maintained
     checks.
@@ -860,7 +862,7 @@ Parameters:
 Return value:
 
     FLAG : TRUE iff mv is eligible to be considered for pruning or
-    reduction (EFP/LMP/LMR still each apply their own further checks
+    reduction (LMP/LMR still each apply their own further checks
     on top of this).
 
 **/
@@ -1081,7 +1083,7 @@ Routine description:
     for a move either of those would have exempted. Takes the FH-table
     lookups (uFHAttempts, uFHPctThousandths, uPredictedFH) as inputs
     rather than recomputing them -- search.c's move loop already looks
-    them up once per move for LMP/LMR/EFP to share.
+    them up once per move for LMP/LMR to share.
 
     2026-10-13: corrected from an earlier version of this comment that
     claimed four checks including a move-number floor and a depth
@@ -1141,8 +1143,8 @@ Return value:
 
     FLAG : TRUE iff mv should be pruned outright (skipped, not merely
     reduced). Live, not audit-only: search.c's move loop actually
-    `continue`s past mv when this returns TRUE (the same final check
-    that consumes fThisMoveEFPPruned), after INCrementing
+    `continue`s past mv when this returns TRUE (the check that
+    consumes fThisMoveLMPPruned), after INCrementing
     u64LMPPruned for the script-summary "late-move pruning (overt
     skip, not reduction)" line under PERF_COUNTERS.
 
@@ -1325,8 +1327,8 @@ ComputeMoveScore(IN SEARCHER_THREAD_CONTEXT *ctx,
         ASSERT(IS_SAME_MOVE(mv, ctx->sMoveStack.mvf[uMoveNum].mv));
         ASSERT(ctx->uPly > 0);
 
-        // Every current caller (search.c's EFP check, and
-        // ComputeMoveExtension's two ComputeMoveScore() call sites) only
+        // Every current caller (EstimateHangingMaterialCp above, and
+        // ComputeMoveExtension's own call site below) only
         // reaches here after MakeMove(ctx, mv) has already succeeded, so
         // ctx->uPly is always the *child's* ply here -- uMoveNum indexes
         // the parent's move list, i.e. ctx->uPly - 1, not ctx->uPly. That's