carrying the running score into the result

[andy-k]

Summary

the endgame and pre-endgame (PEG) solvers only value the tiles left to play from here; they know nothing of each side's score so far. because the CLI took no score input, its printed win/draw/loss for the PEG case was actually judging only the rest of the game, so a mover already losing by a wide margin on the board could be told "win" for a positive rest-of-game value, which is not the same as winning the actual game. this PR adds an optional fourth CLI argument, score_diff (the mover's current score minus the opponent's, default 0), and threads it into the value before any win/draw/loss decision, so the printed result reflects the whole game rather than just its tail. the accompanying lab/endgame.txt doc is updated to describe carrying the running score into the result.

Root cause

the solvers only ever value the remaining tiles and never saw each side's running score. the CLI passed no score in, so the PEG win/draw/loss judged only the rest of the game -- a mover losing by a wide margin on the board could be reported as a "win" purely from a positive rest-of-game value.

Changes

• add an optional fourth CLI argument, score_diff (mover's current score minus opponent's, default 0)
• solve_peg_one_in_bag now takes a scaled score_diff and adds it to every hypothesis's margin before aggregating, so win_pct and expected_margin reflect the whole game
• the plain empty-bag branch prints a new line, current score plus the solver's own value; evaluate() now returns that value instead of discarding it (a pure refactor of its existing return path)
• update lab/endgame.txt to describe carrying the running score into the result

Correctness

with the default score_diff = 0 the output is byte-identical to before this PR for every case except the one new printed line and the demo's own new line in the plain branch; the demo is otherwise untouched.