Fix iExtensionAmount write slot and staleness in HelpSearch()

HelpSearch()'s per-move loop wrote ctx->sPlyInfo[ctx->uPly]
.iExtensionAmount after MakeMove had already advanced ctx->uPly,
landing in the child's ply slot instead of the mover's own -- so a
node one ply below a split-originated reduced move could never see
that reduction via (pi-1)->iExtensionAmount (searchsup.c's null-move
history-reduced-bailout check reads exactly that). Search()'s own
move loop binds pi before MakeMove, so its equivalent write needs no
adjustment; HelpSearch() needs the explicit -1 to land in the same
place post-increment.

Also only wrote the value when a move was actually reduced (iLMR < 0)
rather than unconditionally every move -- the same staleness bug
Search() itself used to have and already fixed (see its own comment
at the unconditional write), where a later sibling move at the same
ply could inherit a stale reduction value a different, earlier move
left behind.

Both fixes bring HelpSearch() in line with Search()'s already-correct
convention: a single unconditional write to ctx->sPlyInfo[ctx->uPly
- 1].iExtensionAmount after the reduction decision, for every move.

Only reachable through a real split (multithreaded search), which is
why this was easy to miss. Verified via precommit_check.sh (TEST=1
self-test suite + debug_smoke_test.sh), both pass.

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

0 files changed, 0 insertions, 0 deletions