NNUE accumulator correctness test; fix king-capture backup-ordering bug

testnnue.c (new, TEST=1): TestNnueAccumulator proves the one property
nothing else checked -- that SEARCHER_THREAD_CONTEXT.sNnueAccum stays
equal to a from-scratch NnueAccumRecompute through real move
sequences. Fills the (otherwise all-zero placeholder) embedding table
with distinctive, deterministic values first: an all-zero table would
let a broken feature-index formula "pass" trivially, since every row
sums to zero regardless of which squares/pieces are involved. Plays
real games 2 plies deep from curated FENs chosen to reach captures,
promotions, en passant, castling, and plain king moves quickly, and
compares after every MakeMove and every UnmakeMove -- 2+ plies of
recursion is what exercises PLY_INFO.sNnueAccumBackup's per-ply
indexing (two king moves at different, not-yet-unmade plies must not
collide), which a single-ply test could not have caught.

It caught a real bug on its very first run: move.c's MakeMove backed
up the king's own-perspective accumulator *after* a capture's
LiftPiece call instead of before it. For a king capturing a piece
(e.g. Kxd7), LiftPiece already removes the captured piece's feature
from both perspectives -- including the king's own -- before the
backup snapshot was taken, so the backup captured a state already
missing the captured piece. UnmakeMove correctly resurrects the
captured piece via PlacePieceWithoutSigs, but then immediately
overwrote that correct state with the stale backup. Fixed by moving
the backup to the top of the ordinary (non-castling) king-move
handling, before any mutation for that move happens at all -- the
castling branch was already backing up before its own moves and
needed no change.

Verified via the full precommit_check.sh (all 4 gates, including the
combined DEBUG=1 TEST=1 self-test, which now runs this test too).

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

0 files changed, 0 insertions, 0 deletions