feat: add Mathpix PDF extraction

[m-messer]

in2lambda/wizard/mathpix.py: pdf_to_markdown() uploads a PDF to the Mathpix OCR API, polls for the rendered markdown, downloads any remote figures into <out_dir>/media/, and repoints the markdown at ./media/<name> so the Markdown filter's image resolution finds them.

• Credentials from $MATHPIX_APP_ID / $MATHPIX_API_KEY; a missing pair raises a clear RuntimeError.
• Only needs requests (already a core dep), so the module imports without the llm extra.
• Ported and cleaned up from conversion2025/converter.py on Summer2025: print/exit calls become exceptions, the PIL round-trip is dropped (bytes stream straight to disk), poll interval/count are parameters.
• Tests mock all HTTP.

⚠️ Not yet exercised against the live Mathpix service — tests are fully mocked. Live PDF run pending.

---

Stack: llm-client ← mathpix ← wizard-command
Base: llm-client — #25.

🤖 Generated with Claude Code

[peterbjohnson]

Notes from review. The shape of this is fine; it's the failure paths that need work before it goes near a real PDF.

No timeouts. None of the three HTTP calls (mathpix.py:60, :80, :95) pass timeout=, so a stalled connection hangs the command indefinitely with no way to tell what's happening.

Polling treats every failure as "not ready yet" (:79-84). Any non-200 response, whether that's a bad API key, an unknown id, a server error or a conversion that failed outright, just sleeps and retries. The user waits the full five minutes and is then told the conversion "did not finish in time", which sends them looking in the wrong place. Polling GET /v3/pdf/{id} for the conversion status and raising on an error status would report the real problem in seconds.

response.json()["pdf_id"] (:64) raises a bare KeyError when Mathpix returns an error body, which reads like a bug in in2lambda rather than a rejected upload.

It can overwrite a file the user cares about. pdf_to_markdown writes <pdf stem>.md into out_dir (:68-70), and in the wizard PR out_dir is the folder of the user's chosen output file. So in2lambda wizard notes/paper.pdf -o notes/draft.md silently replaces notes/paper.md if it exists. Returning the markdown as a string, and only writing the figures, would avoid it entirely.

Failed figure downloads are skipped silently (:95-97), leaving the markdown pointing at a local file that was never written. A warning would do.

Two more, both worth a line in the docs rather than code: the PDF is uploaded to a third party, which teachers should be told about, and Mathpix has a training opt-out that we probably want set. Also, has this been run against the real service yet? The tests mock it, so what they check is our assumptions about the API rather than the API itself.

[m-messer]

Pushed 662e20c addressing the review points:

• Timeouts: all three requests calls now take a timeout (default 30s, configurable).
• Polling: now polls GET /v3/pdf/{id} for status instead of the .md endpoint. HTTP errors raise immediately via raise_for_status(), and a status: "error" body raises right away instead of waiting out the full poll budget.
• Bare KeyError: the upload response is checked for Mathpix's in-band "error" field before indexing pdf_id, raising a clear RuntimeError instead.
• Overwriting the user's file: pdf_to_markdown now returns the markdown as a str instead of writing <stem>.md into out_dir. It still writes figures to <out_dir>/media/; the caller decides where the markdown text goes.
• Silent figure failures: now warnings.warn(...) on a non-200 download instead of a silent continue.
• Docs: added a note to the module docstring that PDFs go to Mathpix (third-party OCR) and that Mathpix offers a training opt-out.

Tests updated to match (two-step poll mocking, plus new cases for a rejected upload, an immediate conversion error, and a failed figure download warning). Still not run against the live service — that's still pending, as noted in the PR description.