Fix: brute-force xref scan loses stream position, missing recoverable trailers

[jeske]

Problem: brute-force xref scan loses stream position, missing recoverable trailers

PdfDocument.Open throws "Could not find an xref trailer or stream dictionary in the input file"
for some malformed-but-recoverable PDFs - even under lenient parsing - that Acrobat/Foxit open fine.

Repro: PDFium's Type3 test file ships a deliberately broken xref section:

pdfium_type3_basic.pdf

xref
0 
trailer
<< /Size 0 /Root 1 0 R >>
startxref
0
%%EOF

The body objects and the trailer dictionary itself are perfectly valid — only the xref machinery
around them is broken.

Root cause

XrefBruteForcer.FindAllXrefsInFileOrder scans the input byte-by-byte and has a handler that
captures a backup trailer dictionary — but it never fired for this file. When the scan hits
" xref" it calls XrefTableParser.TryReadTableAtOffset, which seeks the shared IInputBytes
and does not restore position on failure. The failed parse of the malformed table left the stream
positioned past the trailer keyword, so the scan loop never saw it → LastTrailer stayed null
→ PdfDocumentFactory threw. The same hazard exists in the "/XRef" stream branch.

Fix

• Snapshot bytes.CurrentOffset before the nested table/stream parse attempts and seek back
  afterwards, so the byte scan always resumes where it left off.
• Seek the token scanner to the scan position before reading the backup trailer dictionary, since
  a preceding failed parse may have moved it elsewhere.

No behavior change for well-formed files (the brute-forcer only runs when direct xref parsing has
already failed), and no change to non-lenient error behavior.

Verified

• The PDFium type3 file now opens; page content parses and renders correctly.
• Existing test suite passes.

[BobLd]

@jeske can you add a test with the document you provided? The change looks good to me