King attack-table population: bitboard rewrite, fixes a real bug and a real asymmetry

_EvalKing was the last piece type contributing to the old bvAttacks/
ATTACK_BITV mechanism -- both write sites (the low-enemy-material
early-exit path and the main king-safety loop) replaced with a single
pos->bbKingAttacks[uColor] |= g_KingAttacksBB[c], plus a new
_IsSquareAttackedByKing transitional helper (DEBUG-cross-checked, no
x-ray companion needed since a king can't move through a blocker) for
_WhoControlsSquareFast and _EvalKing's own bvDefend to read.

Two real, intentional behavior changes land with this conversion,
both discussed and confirmed before coding rather than assumed:

1. The main king-safety loop's old per-square write used
   KingSafetyDeltas (11 entries: the 8 real king-move squares plus -2/
   +2, two squares away on the same rank, present only for that loop's
   own file-distance bookkeeping) instead of the real 8-square king
   move pattern -- a bug, confirmed by direct instruction, not a
   design choice worth preserving. Fixed by writing the real
   g_KingAttacksBB[c] pattern once, before the loop, instead of
   whatever KingSafetyDeltas happened to visit per-square.

2. _EvalKing's own bvAttack computation (does the *enemy* king attack
   a square near this king?) is now symmetric where it used to be an
   accidental artifact of evaluation order: kings are evaluated
   black-then-white, so the old mailbox code let white's computation
   see black's already-written king bit while black's could never see
   white's (white hadn't run yet). Rather than preserve or upgrade
   that asymmetry now that both colors go through an explicit helper
   either way, neither side sees the enemy king as a threat here,
   matching the side that already couldn't -- by direct instruction.
   This is narrow in practice (two kings can never be legally
   adjacent, so it only ever fires at king-vs-king distance 2) but
   real.

_WhoControlsSquareFast's own king contribution is unaffected by either
change and stays fully symmetric: it's only ever called after *both*
kings finish evaluating (the passed-pawn re-check and trapped-piece/
danger passes all run after Eval()'s king-eval block), so
pos->bbKingAttacks is always fully populated for both colors by the
time it runs -- confirmed by checking call-site ordering directly, not
assumed from bvAttack's own (different) situation.

CountKingSafetyDefects is untouched by this change (confirmed by
reading it again): it's pure CHECK_VECTOR geometry over piece
locations, computed before any bbXAttacks accumulator exists this
Eval() call, and reads none of them. Its correlation with _EvalKing's
score is therefore preserved by construction, not something requiring
separate re-tuning.

Verification: since this bundles three attributable behavior changes
(the bitboard rewrite itself, the KingSafetyDeltas bug fix, and the
dropped bvAttack asymmetry), used the ringers-suite-plus-bounded-delta
bar from bishop's conversion rather than expecting exact node-count
equality: precommit_check.sh (self-test + DEBUG smoke test, plus
several hand-built king-adjacency/king-proximity positions run
directly against a DEBUG binary to exercise the new cross-check) all
pass; whole-engine tests/ecm_ringers.ep_ at sd10 vs. the immediately
preceding commit holds exact solve parity (10/11 both), with
per-position node-count deltas (-50% to +76%) all attributable to the
three documented changes above, no unexplained outliers.

ATTACK_BITV/bvAttacks itself is intentionally left in place -- nothing
writes it any more (king was the last writer), but the struct deletion
and the resulting simplification of the transitional
_IsSquareAttackedByX/_IsSquareXrayedByX helpers (which collapse to
plain bitboard reads once nothing can ever populate the old structure)
is staged as a deliberate follow-up commit, not bundled here.

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

0 files changed, 0 insertions, 0 deletions