Fix RescoreMovesViaSearch's fail-high handling: stop destroying the

winning move's own score, and stop discarding generate.c's ordering
information for moves it never got to search.

Two bugs, found while reading this function to understand it:

1. On fail-high, `goto end` jumped past the for loop's own x++, so x at
   the `end:` label still pointed at the move that just failed high --
   whose iValue had just been correctly set to its real score two lines
   earlier. The clearing loop then started at that same x, immediately
   overwriting the winning move's own just-computed score with
   -INFINITY: exactly backwards, marking the one move IID found good
   enough to fail high on as worst-possible, while the inferior moves
   it beat kept their real scores and would be preferred instead.

2. Even with that fixed, every move after the winner was still set to
   -INFINITY -- total, deliberate amnesia about generate.c's original
   ordering estimate for moves we simply didn't get to (a fail-high
   means we stop early on purpose, to avoid burning nodes confirming
   what we've already decided to play). If the winner's fail-high
   doesn't hold up at full depth, the caller falls back to a list where
   every remaining move is a tied -INFINITY -- worse than never having
   run IID at all for that tail, and inconsistent with -INFINITY's use
   elsewhere in this function for genuinely-known-illegal moves.

Restructured to defer committing to mvf[].iValue until it's known
whether every move got an honest, fully-searched score (scores go into
a local scratch array during the loop instead of directly into the
move stack). On full completion, commit all of them and set
fMovesRescoredByIID as before. On fail-high, commit nothing -- leave
every move's original generate.c ordering value untouched, and bump
just the winning move into killer-tier territory (same trick
generate.c uses for a real killer move) so the normal, non-rescored
selection path still tries it first. fMovesRescoredByIID stays FALSE
in this case, since the ply's iValue is back to being generate.c's
ordering encoding, not real scores.

Measured (ecm_ringers.ep_/ecm_confident_quick.ep_/ecm_hard_quick.ep_,
sn=5M): 10/88/9, recovering the confident_quick point lost by the
previous IID-trust commit (was 10/87/9) with no cost elsewhere.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01YGSMkwjqiCk4XhbfN7ugD2

0 files changed, 0 insertions, 0 deletions