Web search / web_fetch tool returns raw PDF binary instead of extracted text

Description: When the model uses the web_fetch (or web search) tool on a URL that points directly to a PDF file, the tool returns the raw binary content of the PDF instead of extracting the text. The model then receives unreadable compressed stream data and incorrectly concludes the file is "corrupted," even when the PDF is perfectly valid.

Steps to reproduce:

1. Enable web search in Page Assist.
2. Ask a question that leads the model to fetch a PDF result, e.g. a direct link like:
   • https://www.canadalite.com/Pdf/Philips/Advance%20Ballasts%20for%20Germicidal%20UV%20Lamp%20Applications.pdf
   • https://www.uvgermi.fr/download/documents/produits/49/Fiche%20technique%20UVPLUS%20W60.pdf
3. Observe the tool output.

Actual behavior: The tool output starts with raw PDF structure (%PDF-1.x, stream/endstream, FlateDecode blocks, xref tables, etc.) instead of extracted text. Both PDFs above are well-formed (verified with %PDF-1.x headers, valid xref tables), not corrupted. The model then reports the file as "corrupted" or "binary" based on this raw content.

Expected behavior: When the fetch target's Content-Type is application/pdf (or the URL ends in .pdf), the tool should route through the existing PDF text-extraction pipeline already used for imported/knowledge-base PDFs (pdf.js-based), rather than returning raw bytes for web-fetched PDFs.

Environment:

• Page Assist version: [1.5.76]
• Browser: [Chrome Version 151.0.7922.72 (Build officiel) (x86_64), Vivaldi Version 8.0.4033.28 (Version officielle) (x86_64) version de Chromium 148.0.7778.183]
• Backend: Ollama (local, Version 0.32.5)

Additional context: Similar issues have been reported in other LLM-tool projects for the same root cause — raw PDF bytes passed to the model instead of extracted text (e.g. open-webui/open-webui #23841, anthropics/claude-code #23694).