Bug: `WebSearch` can trigger a native macOS “Save As” dialog on PDF/download result URLs, and the saved file is not read back by AI

```

That indicates WebSearch tried to access a PDF/download-style URL while enriching results.

## Why this points to WebSearch

The dialog appeared immediately after the WebSearch call above.

The next calls in the thread were WebFetch calls against ordinary HTML article pages, for example:

- https://example-journal-site.invalid/article/.../full

- https://example-repository.invalid/articles/<redacted>/

Those returned contentType: text/html, so they were not the source of the save dialog.

## Expected behavior

When WebSearch encounters result URLs that are PDF-like or download-like, it should:

- skip preview/snippet enrichment for those URLs, or

- route them through a controlled PDF pipeline

It should not trigger an OS-level save dialog during search result processing.

## Actual behavior

- WebSearch touches a result URL with download=true

- macOS shows a native “Save As” dialog

- the user saves the file manually

- Alma does not read the saved file or attach it to the workflow

## Likely cause

WebSearch result enrichment is treating PDF/download targets like normal web pages.

URLs with patterns like these need special handling:

- .pdf

- content/pdf

- pdfCoverPage

- pdfdirect

- download=true

## Recommended fix

1. Add PDF/download URL detection before result enrichment.

2. Do not open those URLs in the normal preview/snippet path.

3. Either skip enrichment or download programmatically to a temp path and parse the file.

4. If a file is downloaded, pass the saved path or extracted text back into the tool result.

## Impact

This breaks research workflows in two ways:

- unexpected native OS dialog interrupts the user

- the downloaded file becomes orphaned because Alma never reads it