eval.c: defer B/N/R mobility scoring near enemy king, queen king-adjacency fix, FLIP() -> precomputed xColor

Bishop/knight/rook mobility computed during their own eval pass only
sees enemy pawn (B/N) or pawn+minor (R) attacks -- a square right next
to the enemy king looks "safe" and counts toward mobility even though
it plainly isn't (e.g. a pawn push cutting off a bishop's retreat onto
squares next to the enemy king). Below EVAL_MOBILITY_CAREFULLY_BELOW
(3) candidate squares, defer scoring to _EvalTrappedPieces, which
re-derives the true safe-escape count once every piece type -- the
enemy king included -- has contributed to the attack tables. Genuinely
0-mobility pieces are scored immediately instead: more attack info can
only shrink an already-empty set, so there's nothing to gain by
waiting.

Queen doesn't need deferral (its own eval pass runs after every
smaller piece type, so it already has complete information) -- instead
bbUnsafeForQueen now also excludes squares adjacent to the enemy king
unless we already defend them.

Also: precompute xColor = FLIP(uColor) once per function/loop
iteration everywhere eval.c could hit FLIP() more than once evaluating
it, instead of recomputing it at each use site.

Verified: precommit_check.sh (self-test + DEBUG smoke test) clean.
Curated ECM suites at sd10 vs head_reference: ecm_ringers 4/11 (was
3/11), ecm_confident_quick 70/90 (flat), ecm_hard_quick 19/90 (was
18/90) -- no regressions. Overnight self-play SPRT trending positive
(370 games, llr=+0.20).

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

0 files changed, 0 insertions, 0 deletions