[BUG] Read tool falsely reports unencrypted pandoc/LaTeX PDFs as 'password-protected'

What happened

The built-in Read tool's PDF path returns:

PDF is password-protected. Please provide an unprotected version.

…for PDFs that are not encrypted at all (no /Encrypt dictionary, no user/owner password). This forces the user to "provide an unprotected version" that already exists, or abandon the read — wasting tokens and time on a false premise.

Repro

1. Export a PDF via pandoc or pdflatex/LaTeX (these commonly produce PDFs with compressed object streams + cross-reference streams rather than a classic xref table).
2. Read the .pdf.
3. Observe the false password-protected error.

Evidence it is NOT encrypted

Raw byte scan for /Encrypt across the affected files returns nothing (no encrypt dictionary present):

data = open(p, "rb").read()
print("/Encrypt" in data.decode("latin1"))   # -> False for every file

And pdftotext -layout file.pdf out.txt (poppler) extracts the full text cleanly with no password. So the documents are plain, unencrypted PDFs.

Expected

• The Read PDF parser should not report password-protected unless an /Encrypt dictionary actually requires a password.
• For PDFs it cannot parse (object streams / xref streams), it should emit an accurate error (e.g. "could not parse PDF structure") and/or fall back to pdftotext/poppler — not blame encryption.

Impact

This is not a one-off. Every pandoc/LaTeX-exported PDF the user reads hits this. The misleading error sends both the user and the agent down a dead-end ("set a password? remove a password that was never set?"). Misdiagnosis = repeated wasted turns.

Workaround (works reliably)

pdftotext -layout "<input.pdf>" out.txt

then read out.txt. Poppler handles these PDFs fine, confirming the files are valid and unencrypted.

Environment

• Claude Code on Windows
• PDFs produced by pandoc / pdflatex (TeX Live 2024)
• poppler pdftotext available and succeeds on the same files