Restore 5D-alpha + 4D-beta FH% collection (improve axis + whole-node bucket), fix two bugs found via validation

Restores the full dual-table FH% collection instrumentation under
FH_TABLE_COLLECTION, which had regressed to a 4D-only alpha joint with
no beta side at all (see the prior commit's note): adds back the
`improve` axis to the alpha joint and a new 4D beta joint (depth,
gap-to-beta, own-improve, enemy-improve), both with real INC() call
sites and ALPHARAW/BETARAW/ESTRAW dump lines matching dual_table_run/'s
existing (unmodified) aggregate.py/dashboard.py/marginal_crosscheck.py
parsers exactly.

Also adds a genuine NODE-level sample into the alpha table's previously
unused late==0 bucket: "will something at this node fail high" when
iEval <= iAlpha, ground truth = the real move loop's outcome. This is
the alpha-side analog of the beta table (which only covers iEval >
iBeta) -- together they cover every null-window child's self-estimate
with no gap, motivating a follow-up (not part of this change) on
combining a parent's per-move FH% prediction with a child's own
node-level self-estimate for a sharper NODE_CUT/NODE_ALL signal than
CommonSearchInit's current purely-structural PVS alternation.

Collecting real ground truth for both new node-level samples requires
not taking the beta-side static-null-move shortcut's early `goto end`
during collection builds, same reasoning as the existing LMP disable.

Two bugs found and fixed via validation before trusting this for a
multi-day run:

1. goto-skips-initializer: Search()'s early QSearch-depth `goto end`
   jumped over the new collection variables' declarations, leaving
   them uninitialized (indeterminate stack garbage) on that path. Only
   manifested in the release (-O3) build -- a DEBUG (-O0) build worked
   by accident (the skipped stack slots happened to read as zero).
   Caught via lldb on a real segfault: garbage "eligible" flags feeding
   wildly out-of-range array indices. Fixed by moving the declarations
   before the early goto.

2. MAX_SPLITS amplification: the new arrays were nested inside
   COUNTERS.tree, which is embedded both in SEARCHER_THREAD_CONTEXT and
   in split.c's g_SplitInfo[MAX_SPLITS] array -- so the ~19MB growth
   got replicated 64x, inflating the binary's BSS from ~220MB to
   ~1.47GB and breaking valgrind's fixed-address mmap outright (harmless
   at runtime for a --cpus 1 collection shard, since g_SplitInfo's
   copies are never touched, but it also meant any real MP split would
   have silently lost a helper thread's collected data, since no
   merge-back code exists for these fields). Fixed by moving them into
   a new standalone FH_COLLECTION_COUNTERS struct referenced only from
   SEARCHER_THREAD_CONTEXT, not from SPLIT_INFO. BSS dropped to ~281MB;
   valgrind (--track-origins=yes) now runs clean: 0 errors, 0 bytes
   definitely/indirectly/possibly lost.

Validated end-to-end against real NNUE weights (--nnueweights
eval.nnue), release build, full tests/ecm_ringers.ep_ suite at sd 10:
ALPHARAW/BETARAW/ESTRAW all populated (including real late==0 "whole
node" rows), dual_table_run/'s existing aggregate.py and
marginal_crosscheck.py parse it unmodified -- depth/gap/improve axes
match exactly; the only two "mismatches" (dumb and late bucket 0) are
exactly and fully explained by the new whole-node samples, which
deliberately don't feed those two per-move marginals (hang=0/late=0
are placeholders there, not real measurements) -- not a real bug, and
reproduced byte-for-byte identical after the struct relocation above.

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

0 files changed, 0 insertions, 0 deletions