Land super-lazy exit, material-based lazy floor, qsearch futility rework

Brings in the last remaining piece from stash@{0}: the super-lazy exit
point (material-only pre-check before the regular lazy gate), a
material-bucket floor under the regular lazy exit's margin
(iSwingFloorByArmy), and search.c's qsearch futility rework
(FUTILITY_BASE_MARGIN_BY_SOURCE, indexed by which Eval() exit tier
produced the score). Required Eval()'s signature change from a single
SCORE* to SCORE(*)[2] (positional estimate per side instead of one
munged magnitude) -- search.c's futility margin folds in
rgiPositional[pos->uToMove], which the earlier bad-trades investigation
found to be a meaningfully predictive signal.

search.c and chess.h brought in wholesale from the stash (both were
either completely untouched by prior commits or contained no
divergence worth preserving). eval.c required hand-merging on top of
this session's already-applied bad-trades fix, B-over-N removal, and
xColor/reorder cleanups -- ported the super-lazy exit block, the
regular-lazy material floor, the per-color piPositional writes (all
three exit sites: super-lazy, regular-lazy x2, full-eval), the
super-lazy calibration harness (RecordSuperLazyMarginSafetySwing,
dual-regime DumpMarginSafetyCalibration), and moved uArmyScaler/
uNumTrapped initialization to match the new ordering the super-lazy
exit depends on.

Verified: clean release + DEBUG build (only the previously-flagged
_EvalTrappedPieces warning), DEBUG smoke test pass, and a 40-game
st1 match against clean 434fa04 (score 0.487, llr -0.04) -- landing
this margin machinery as-is from the stash, before any retuning, does
not regress strength on its own. This confirms the original
regression (0.15-0.225 score seen early in this investigation) was
fully explained by the bad-trades unsigned-underflow bug, not by these
margins being unsound.

Values are the original, as-derived-from-calibration ones (see
inline comments: SUPER_LAZY_MARGIN_BY_ARMY from 100 positions/sd8
with ~15-20% headroom, iSwingFloorByArmy from 1500 positions/sd8
with ~25% headroom, FUTILITY_BASE_MARGIN_BY_SOURCE from a separate
1500-position/sd6 surprise-rate calibration). Not yet retuned --
suspected to carry more headroom than necessary, which costs real
search speed (speed=depth). Next step: re-run the margin-safety
calibration fresh against the current build and trim the super-lazy
and regular-lazy floor headroom down from the built-in database,
leaving the qsearch futility margins alone (different calibration
method, already risk-tolerant by construction).

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

0 files changed, 0 insertions, 0 deletions