Maintain pos->bbOccupied incrementally, dedupe its two from-scratch builders

chess.h: add POSITION::bbOccupied (full-board occupancy, both colors,
every piece including kings), maintained incrementally alongside
bbPieces/bbPawns rather than rebuilt on demand -- resolves the open
question in EVAL.md section 0 about whether this is worth doing given
both generate.c and the planned eval.c mobility rewrite need it.

move.c: SlidePiece/SlidePawn/LiftPiece/PlacePiece and their
WithoutSigs variants now maintain bbOccupied at the same choke points
that already maintain bbPieces/bbPawns -- unconditionally, since
occupancy doesn't care about piece type or color. Kings only ever
move through SlidePiece/SlidePieceWithoutSigs (never Lift/Place), so
no separate king-specific update site was needed.

fen.c: populate bbOccupied when parsing a FEN.

board.c: VerifyPositionConsistency cross-checks pos->bbOccupied
against a from-scratch rebuild, same pattern already used for
bbPieces/bbPawns.

generate.c/movesup.c/see.c: replace call sites that rebuilt full
occupancy via _BuildFullOccupiedBB/_BuildOccupiedBB with direct reads
of pos->bbOccupied; delete see.c's _BuildOccupiedBB, which was a
byte-for-byte duplicate of generate.c's _BuildFullOccupiedBB (kept
only as the from-scratch ground truth for the new consistency check
and testgenerate.c's benchmark harness).

testsup.c: GenerateRandomLegalPosition builds POSITIONs by poking
rgSquare/bbPieces/bbPawns directly, bypassing both move.c and fen.c --
a third construction path the above missed. It never set bbOccupied,
so the new VerifyPositionConsistency check failed on every generated
position, and since generation retries until a position verifies, the
self-test suite spun forever (100% CPU, no progress) instead of
crashing outright. Fixed by setting bbOccupied at all four placement
sites (both kings, pawn, non-pawn piece). Full self-test suite and
precommit_check.sh verified clean afterward.

board_representation/EVAL.md: record the bbOccupied decision and
rationale, resolving section 0's open question.

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

1 files changed, 10 insertions, 0 deletions

diff --git a/src/board.c b/src/board.c
index 0b195be..814b045 100755
--- a/src/board.c
+++ b/src/board.c
@@ -170,6 +170,7 @@ Return value:
         "Fifty move counter is too high",
         "bbPieces bitboard doesn't match piece list",
         "bbPawns bitboard doesn't match pawn list",
+        "bbOccupied bitboard doesn't match piece list",
     };
     ULONG u, v;
     COOR c;
@@ -179,6 +180,7 @@ Return value:
     ULONG uNonPawnCount[2][7];
     BITBOARD bbPieces[2][8];
     BITBOARD bbPawns[2];
+    BITBOARD bbOccupied = 0;
     ULONG uSigmaNonPawnCount[2] = {0, 0};
     ULONG uWhiteSqBishopCount[2] = {0, 0};
     UINT64 u64Computed;
@@ -272,6 +274,7 @@ Return value:
                 uPawnMaterial[u] += VALUE_PAWN;
                 uPawnCount[u]++;
                 bbPawns[u] |= COOR_TO_BB(c);
+                bbOccupied |= COOR_TO_BB(c);
             }
         }
 
@@ -316,6 +319,7 @@ Return value:
                     {
                         bbPieces[u][PIECE_TYPE(p)] |= COOR_TO_BB(c);
                     }
+                    bbOccupied |= COOR_TO_BB(c);
                     uNonPawnMaterial[u] += PIECE_VALUE(p);
                     if ((IS_BISHOP(p)) &&
                         (IS_WHITE_SQUARE_COOR(c)))
@@ -394,6 +398,12 @@ Return value:
         }
     }
 
+    if (pos->bbOccupied != bbOccupied)
+    {
+        uReason = 23;
+        goto end;
+    }
+
     //
     // Now walk the actual board and reduce the material counts we got
     // by walking the piece lists.  If everything is ok then the