Fix PGN parser throwing on ambiguous moves

[Copilot]

The PGN parser failed with "Ambiguous move for Cb6" whenever multiple pieces of the same type could legally reach the same square — it had no disambiguation strategy beyond throwing.

Changes

• Moved ResultCandidate to parser-common.js — extracted from parser-wxf.js so it's available to both parsers (script load order: parser-common → parser-pgn → parser-wxf)

• Replaced single-board approach in PgnParser.parse() with multi-candidate branching — mirrors the existing WXF strategy:

  • 1 candidate → advance normally
  • >1 candidates → fork one ResultCandidate per move; invalid branches are pruned by subsequent moves
  • 0 surviving candidates → throw

• Annotations preserved — tracked separately per-token index and re-applied to the final result, since ResultCandidate.listMoves() returns null annotations

• Fixed attemptToAddMove — removed erroneous this.#valid = true on success that could resurrect an already-invalidated candidate

// Before: throws "Ambiguous move for Cb6 (BLACK to play)"
// After: forks candidates for each legal Cb6 source, prunes via future moves
1. Che3 Nhg8 2. Nhg3 Ch2 3. Rih1 Chf2 4. Ra2 Cfb2 5. Cbc3 Cb6 ...

[benckx]

@copilot I think we already have this system in place when parsing WXF moves so that would be redundant

[Copilot]

ResultCandidate was moved out of parser-wxf.js into parser-common.js (commit bce8456 removes 82 lines from parser-wxf.js), so there's no duplication. It needs to live in parser-common.js because the script load order is parser-common → parser-pgn → parser-wxf, meaning parser-pgn.js can't reference a class defined in parser-wxf.js.