Fix PGN parsing for piece moves to en-passant target squares

[john-sp]

Fixes a PGN reader bug where a non-pawn SAN move landing on the current en-passant target square could be encoded as an en-passant move.

This happened when a double pawn push created an en-passant target, and the following move was a piece move to that same square, such as ...Nb3 after b4. The SAN parser now only creates an en-passant move when the parsed move is a pawn move, leaving normal piece moves encoded normally.

Example PGN that exposes the bug:

1. Nf3 d5 2. c4 dxc4 3. e3 b6 4. Rg1 Ba6 5. g4 Nc6 6. a3 Na5 7. b4 Nb3 *

AI Disclosure:
I encountered this bug, Codex-GPT5.5 found the issue, I verified that its solution was correct and tested it manually.

[Copilot]

Pull request overview

Fixes a SAN/PGN parsing edge case where a non-pawn move that lands on the current en-passant target square could be incorrectly encoded as an en-passant capture. This ensures generated Move objects correctly represent piece moves vs. pawn en-passant captures, preventing illegal/incorrect move encoding for affected PGNs.

Changes:

• Gate en-passant move construction on the parsed piece being a pawn (p == 0) when searching for an ambiguous “from” square.
• Gate en-passant move construction on p == 0 when directly constructing the parsed move.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[borg323]

The PGN parser has many issues, hopefully most of them fixed in #1786. Back then we decided we should implement a new PGN parser if we encounter use cases where the current one is not sufficient. So, how did you run into this?

[john-sp]

I was working on selfplay from PGNs downloaded from H1 2026 from LQO using the latest master build. Lc0 was saying there was illegal moves, so I binary searched to find the PGN game that was causing the issues, found the move and that pointed me to the likely issue. The PGN above is what was causing issues for me. If #1786 correctly can read this PGN, feel free to close this PR.

[borg323]

#1786 is unlikely to be merged in its current form. I'm just checking if your use case may run into other issues as well, and it certainly looks possible...