Pre-existing WalkPV assertion crash (util.c:1093), found 2026-09-08
during the board-representation-migration self-play investigation.

STATUS: confirmed pre-existing on unmodified HEAD (434fa04), NOT
introduced by any of that session's changes. Not yet root-caused.
Reproduces intermittently depending on accumulated hash-table state,
not on the triggering FEN alone in isolation.

Repro (DEBUG build, asserts compiled in):

    ./_typhoon --batch --command "force; setboard rnb1r1k1/pp5p/2pp2p1/4b3/2P1P2q/1NN1BPp1/PP1QB1P1/3RR1K1 b - -; sd 5; go"

Crash happens during the *subsequent* Ponder() call after the "go"
search completes (visible as "_[pondering ...] white(move 1)_" in the
output right before the assertion) -- NOT during the sd 5 search
itself. A bare "sd 5; go" against this FEN with no prior search history
in the process did NOT reproduce it in at least one isolated attempt;
it may depend on hash-table/PV state accumulated from prior searches
in the same process (same category as the second crash found the same
day, recogn.c:1359 _SanityCheckRecognizers -- also state-dependent,
also confirmed pre-existing on 434fa04).

Backtrace (gdb, DEBUG build at 434fa04):

    #0  SystemDebugBreakpoint () at unix.c:405
    #1  _assert (...) at util.c:824
    #2  WalkPV (ctx=0x25d918 <Ponder.ctx>) at util.c:1093
    #3  UtilPrintPV (ctx=..., iAlpha=-421, iBeta=32767, iScore=39, mv=...) at util.c:1214
    #4  RootSearch (ctx=..., iAlpha=-32767, iBeta=32767, uDepth=80) at root.c:857
    #5  Iterate (ctx=...) at root.c:1287
    #6  Ponder (pos=...) at root.c:1592
    #7  MainProgramLoop () at main.c:695
    #8  main (argc=4, argv=...) at main.c:757

At the point of the crash (frame 2, WalkPV locals):
    u = 2, v = 1
    ctx->sPlyInfo[v].PV[u]   == HASHMOVE  (uMove = 286361736,
        cFrom = 136 (0x88, the illegal/off-board sentinel coordinate),
        cTo = 136, pMoved = pCaptured = pPromoted = 1, bvFlags = 1)
    ctx->sPlyInfo[v].PV[u+1] == the SAME non-zero value as PV[u]

WalkPV's <TT> branch (util.c ~1089-1093) matches
`mv.uMove == HASHMOVE.uMove`, then asserts the *next* PV slot is the
zero-terminator:

    ASSERT(ctx->sPlyInfo[v].PV[u+1].uMove == 0);

but PV[u+1] holds the same non-zero "garbage-looking" value as PV[u],
so the assert fires. HASHMOVE itself looks corrupt/never-properly-set
here -- cFrom == cTo == the illegal-square sentinel (0x88) rather than
a real move or a clean zero, which reads like leftover/uninitialized
state being compared as if it were a legitimate hash move.

Not yet investigated further: whether HASHMOVE is stale from a
previous ply/search, whether it's a genuine PV-array corruption during
Ponder specifically (pondering is the only reproduction path found so
far), or something else. This file exists so the exact repro isn't
lost to a later smoke_test run overwriting the same sample filename.