Is the castling key intentionally stripped on null moves?

[grepfuldead]

I've been reading through the move-making code, and I think make_null_move may be leaving the hash in a non canonical state. I'm not sure if that's intentional.

From what I can tell, increment_stack toggles the castling key out on every ply (makemove.rs:9). That looks like the remove old rights half of the pair that make_move completes later at :98. But make_null_move calls increment_stack and never toggles the castling key back in. So after a null move, the castling component is missing from the hash, even though a null move cannot change castling rights.

Concretely, a position reached through a null move hashes differently from the same position parsed from FEN, by exactly ZOBRIST.castling[<rights>].

I think this is probably harmless in terms of correctness: the offset is constant across the null subtree, and I couldnt construct a case where it leads to a bad TT read. It mostly just changes which positions collide/share TT entries. Still, it diverges from the usual convention: Stockfish and Viridithas both leave castling untouched on null moves.

Adding the castling toggle back inside make_null_move removes the divergence, and it also changes bench from "2526370" to "2931707", so it does measurably reshape the search.

Is the current behavior intentional, or is this worth an SPRT to correct? Happy to run it if I can get test access.