UX: apply_patch diff viewer has no height cap when a patch modifies many files

### Self Checks
- [x] I have searched for existing issues, including closed ones.
- [x] I confirm that I am using English to submit this report.
- [x] I have filled in all the required fields.

### Syncless version
Cloud 2026.7.14

### Platform / Device
Web (Browser)

### Steps to reproduce
1. Open a task where an agent has called `apply_patch` with a patch that modifies a large number of files (e.g. 10–20+ files).
2. Expand the tool call detail card.
3. Scroll through the expanded detail body.

### ✔️ Expected Behavior
The diff viewer should be bounded in height. For example, after N files (or beyond a certain total height), the remaining file cards could be collapsed by default, hidden behind a "Show N more files" toggle, or the entire viewer capped with a scroll container — so the tool call card does not push all subsequent chat content far down the page.

### ❌ Actual Behavior
Each modified file is rendered as an individual `` collapsible card, and all cards stack vertically with no total-height limit. For patches touching many files, the tool call detail area grows unboundedly long, making the conversation very difficult to scroll through.

### Additional context
Each individual file diff view already has a `max-h-[420px]` scroll cap, so per-file height is controlled. The missing constraint is at the multi-file list level. A simple mitigation could be: show the first 3–5 file cards expanded by default and collapse the rest behind a disclosure control.

Start by locating the apply_patch diff viewer and its multi-file rendering. Inspect how individual file cards are assembled, then verify that a patch affecting many files no longer creates an unbounded detail area and that the remaining files remain accessible.

Written by the indexing model from the issue text.