Fix draw-score bug in hash-hit path; centralize as g_iDrawScore[2]

Search()'s Dieter-Brusser hash-hit-leads-to-draw check only verified
that a score of 0 would clear the same alpha/beta bound as the stored
iScore -- it didn't establish that iScore itself was accurate. Since
playing the hash move actually produces a draw, propagate the draw
score upward instead of the stale score computed along a different,
non-repeating path.

While fixing this, centralized every other place that returned a
literal 0 for a draw (search.c's stalemate leaf, searchsup.c's
QSearch draw leaf, probe.c's EGTB draw case, which had a dead
`// g_iDrawValue[...]` comment suggesting this was intended all
along) into a single g_iDrawScore[2] global in draw.c, declared in
chess.h. It's indexed by side to move rather than a scalar so a
future contempt-factor tweak can bias the draw score per color
without touching every call site again; both entries are currently 0,
so behavior is unchanged except for the hash-hit bugfix above.

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

0 files changed, 0 insertions, 0 deletions