Knight mobility: bitboard rewrite, first bbMinorAttacks contributor

_EvalKnight's mobility loop (per-square g_iNDeltas delta-walk +
NMobCaseTable switch dispatch) replaced entirely with
g_KnightAttacksBB[c] (generate.c's precomputed table, already used by
move generation) plus two bitboard masks -- knights never x-ray or
have a battery partner, so the old four-case table collapses to
"enemy non-pawn: count unconditionally" and "empty-or-enemy-pawn:
count unless pawn-unsafe."

Adds POSITION::bbMinorAttacks[2] (chess.h), the first of the
bbMinorAttacks/bbRookAttacks/bbQueenAttacks accumulators from
board_representation/EVAL.md section 2 -- knight ORs its full attack
set in directly, no per-square bit-scan needed. Bishop is not
converted yet and still writes its own minor-bit contribution into
the old per-square rgSquare[c|8].bvAttacks structure.

Since knight stopped writing that old structure, every consumer that
needs "does any minor attack this square" (rook/queen's mobility-
safety check, king's danger computation, _WhoControlsSquareFast) now
goes through a new transitional helper, _IsSquareAttackedByMinor,
which ORs the new bitboard (knight) with the old bvAttacks bit
(bishop) in exactly one place rather than each call site hand-rolling
its own combination -- this collapses to a plain bbMinorAttacks read
once bishop converts too, and the helper goes away entirely.

_IsSquareAttackedByMinor is DEBUG-asserted against an independent
recomputation (g_KnightAttacksBB / _BishopAttacksBB, both already-
trusted primitives from move generation, unrelated to either the old
ray-walk's bit bookkeeping or the new accumulator) so a bug in either
mechanism fails loudly in any DEBUG build/smoke-test run rather than
silently drifting into a wrong score deep in search.

Verified via precommit_check.sh and a direct before/after node-count
comparison (sd10, r1bq1rk1/pp2bppp/2n1pn2/2pp4/3P4/2NBPN2/PP3PPP/
R1BQ1RK1 w - - 0 1): byte-identical, 3125335 nodes both builds.

This landed as a deliberately small, single-piece-type step after an
earlier attempt to convert knight+bishop+rook+queen+king in one
combined change produced a real bug (a byte-scale mismatch in xray
bit reconstruction) that was hard to isolate with five things changed
at once, and was reverted back to 6e86450 rather than debugged
further. Bishop, rook, queen, and _EvalKing's own conversion are
follow-up steps, each to be landed and verified the same way, one at
a time.

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

0 files changed, 0 insertions, 0 deletions