Harden ReadManyFilesTool: Concurrency Control and Defensive Guards

### Problem

`ReadManyFilesTool` currently relies on optimistic execution and assumes small, targeted file reads. Since the tool is LLM-driven, it can receive overly broad glob patterns (e.g., `**/*`, `src/**/*`), which may trigger large-scale file ingestion.

The current implementation lacks several defensive safeguards:

1. **Unbounded Parallelism (EMFILE Risk)**
All discovered files are mapped to `readFile` promises and executed using `Promise.allSettled`.
In large repositories this can exhaust OS file descriptors, resulting in errors such as:
```
EMFILE: too many open files
```

2. **No File Count Guard**
There is no limit on the number of files processed in a single request. Reading thousands of files can cause large memory spikes and may lead to Gemini API request failures (e.g., `400 Bad Request`) due to context size overflow.

3. **Missing Bulk File Size Protection**
Although a global 20MB limit exists, bulk reads should enforce a much smaller per-file limit to prevent large files from consuming the model's context unnecessarily.

4. **Inefficient Binary Handling**
The tool performs binary detection by reading file headers for every matched file, which results in unnecessary I/O during large glob operations.

---

### Proposed Solution

Introduce a **Defensive Read architecture** for `ReadManyFilesTool`:

- **Concurrency Control**
- **`max_files` Parameter**
- **Bulk File Size Guard**
- **Standard Directory Exclusions**