Add conservative Teams-aware reverse futility pruning

[KnightStackSys]

Shallow non-PV Teams nodes currently search even when their static team evaluation exceeds beta by a large margin. Add conservative reverse futility pruning on current main (9b40200) without importing the old RFP branch's unrelated merge history. Supersedes #28; its complete tip (dcefe70) is preserved as archive/rfp-pr-28.

RFP runs after TT/mate-distance cutoffs and before NMP. At depths 1–4 it returns staticEval - 200 * depth when that estimate reaches beta. It retains the moving team's score perspective for all four seats, records raw evaluation on the current search stack, and reuses it for NMP without changing NMP's policy.

Guards exclude root/PV nodes, null-move child nodes, mate windows/scores, either allied king in check, and movers without non-pawn material. Candidate cutoffs also require all four players/kings, no checked enemy king or terminal king capture, no pawn one step from promotion in any orientation, and at least two legal moves. This preserves immediate terminal scores, stalemate, forced moves, partner threats and promotion handling. The cutoff does not store an exact TT result or invent a best move.

Validation:

• MSVC 19.51 x64 Release build succeeded; CTest 4/4 passed. Initial executable startup was delayed, but every test completed successfully. Existing getenv deprecation warning in main.cpp remains.
• GCC 16.2 Debug build succeeded; CTest 4/4 passed with assertions enabled.
• New regression covers every seat, depth/margin boundaries, PV/root/null-child/mate exclusions, both allied checks, terminal king-capture mate distance, four promotion directions, missing/eliminated players, stalemate, forced moves, and board/hash restoration.
• GCC Debug UCI smoke: normal and MultiPV=2 searches each completed at 10,000 nodes with valid best moves and expected info output; clean quit.
• git diff --check passed.

The safety checks add candidate-cutoff overhead and RFP remains a selective heuristic. No Elo gain is claimed. Paired fixed-node/fixed-time games and a predeclared SPRT against the same main revision are still needed before strength claims or more aggressive tuning. See docs/reverse-futility-pruning.md for placement, Teams semantics, initial settings, risks and testing guidance.