OpenWiki's `read-tool` MIME type detection logic, specifically its failure to correctly classify common text files (e.g., `Makefile`, `Dockerfile`) and its incorrect handling of binary files when interacting with the Anthropic provider.

## Summary

`openwiki --init` / `--update` reliably crashes mid-run with Anthropic provider on any real-world repo:

```
400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.56.content.2.tool_result.content.0.document.source.base64.media_type: Input should be 'application/pdf'"}}

Troubleshooting URL: docs.langchain.com/oss/javascript/la...
```

## Root cause

The read-tool MIME detection in the bundled `deepagents` dist (`langsmith-*.js` / `langsmith-*.cjs`) is extension-map based:

```js
function getMimeType(filePath) {
return MIME_TYPES[extname(filePath).toLocaleLowerCase()] || "application/octet-stream";
}
function isTextMimeType(mimeType) {
return mimeType.startsWith("text/") || mimeType === "application/json" || mimeType === "application/javascript" || mimeType === "image/svg+xml";
}
```

Two problems:

1. **Any file whose extension is not in `MIME_TYPES` falls back to `application/octet-stream`** and is treated as binary → base64 `document` block. This includes perfectly ordinary text files every repo has: `Makefile`, `Dockerfile`, `Caddyfile`, `LICENSE` (Node `extname()` returns `""` for extensionless files — the `.makefile`/`.dockerfile` map entries never match them), plus `uv.lock`, `*.mermaid`, `*.mako`, `.env.example`, etc. So the agent crashes as soon as it reads a Makefile.
2. **Actual binary files (.png, .xlsx, .docx) are also sent as `document` blocks**, but the Anthropic Messages API ...