feat(desktop): tailor tool result rendering to the content

## Problem

Maka currently renders most tool details through the same generic text and JSON presentation. This makes useful results harder to scan and gives long, low-value output the same visual treatment as diffs, errors, and actionable status messages.

`WebFetch` is the clearest example. Runtime converts HTML to readable Markdown, but the UI still presents the fetched page as a generic text result. A reader must open a large block of content to find basic information such as the URL, page title, or a short summary.

Other tools have the same mismatch:

* Retrieval tools can return many lines or matches.
* Large JSON results can dominate an expanded detail panel.
* Status-only results can expose redundant detail controls.
* Subagent results are more useful as a status, summary, and navigation target.
* Shell, diff, search, workflow, and media results already need their own presentation.

## Desired outcome

Each tool result should show the smallest useful summary by default and keep complete content available through an explicit, bounded detail view.

The presentation should depend on the tool and the result content:

* `WebFetch` success shows a citation card: page title, external link, and size/line count, with a truncation note when the runtime bounded the body. A failed fetch keeps its raw text so the error stays readable. The fetched body itself is not rendered in the UI; the page is reachable through the link and re-derivable by fetching again.
* `Read`, `Grep`, `Glob`, and `Find` show a bounded initial result and a count when available.
* Large text and JSON results show a compact summary before their full content.
* Diffs, shell output, search results, workflows, media, and agent results continue to use specialized previews.
* Status-only results show the actionable state without an empty or redundant detail panel.
* Unknown results use a safe, bounded fallback.

Astryx `ChatToolCalls` remains responsible for group summaries, collapse behavior, row disclosure, keyboard interaction, and accessibility semantics. Maka supplies the appropriate summary and optional `resultDetail`; it should not hide or reimplement Astryx controls.

## Scope and implementation direction

* Extend the existing `standardToolCall` and `ToolResultPreview` paths.
* Add a WebFetch-specific presentation without adding another HTML parser. Runtime already converts HTML to Markdown.
* Add shared bounds for long text, JSON, retrieval results, shell output, and diffs.
* Provide a clear way to view complete content when a preview is truncated.
* Only provide `resultDetail` when the result has meaningful content to inspect.
* Preserve chronological grouping, existing output redaction, durable results, and current specialized renderers.
* Avoid a new renderer registry until the existing dispatch paths become difficult to maintain.
* Avoid CSS selectors that depend on Astryx internal DOM nesting. Use stable component hooks or props when layout access is required.

## Acceptance criteria

A reader can understand what each tool did from its collapsed row or compact preview without opening a large raw result. Detailed content remains available when needed, except the body of a successful `WebFetch`, which is cited rather than rendered. No single result or tool group overwhelms the conversation, and Astryx disclosure and accessibility behavior remain intact.

## Out of scope

* Tool execution, provider responses, or event persistence.
* Changes to chronological tool grouping.
* Replacing Astryx `ChatToolCalls`.
* User-configurable rendering policies.
* Side inspectors, virtualization, or transcript-level group scrolling. The group layout work is tracked separately in #4773.
* Rendering or re-reading the full body of a successful `WebFetch` in the Desktop UI.

## Related work

* #4773 — Bound expanded tool activity in the conversation.
* `docs/tool-result-rendering-strategy-reference.md` — Research on tool-specific result renderers and default output boundaries.