fix(ui): stop tool-well copy button colliding with long first lines and titles

[GabrielDrapor]

Problem

In tool-call detail wells, a long unbroken line — typically a maka://archive/tool-result-archive-… URI — collides with the well's copy button. Two distinct layouts produce the same visual overlap:

1. Headered wells (the reported case): the result headline becomes the Astryx CodeBlock header title, a flex span with white-space: pre and visible overflow. The compact header draws no divider, so the title reads as the well's first content line — and runs straight under the header's copy button, then hard-clips at the container edge.
2. Headerless wells (same collision, different mechanism): Astryx floats the copy button absolutely over the scroll viewport's top-right (copyButtonAbsolute), and wrapped content's first line passes under it — the wrap point is the container edge, not the button edge.

Before

After

Fix (CSS only, scoped to .maka-tool-call-detail)

• Headered: ellipsize the title inside the flex slot the header already sizes (flex: 1 / min-width: 0 on its wrapper). display: block because a flex container will not ellipsize its anonymous text; tool wells never render the collapsible chevron that the flex display exists for. white-space stays pre — both pre and nowrap satisfy text-overflow's no-wrap requirement, but nowrap would collapse runs of spaces, and a title is often a literal path where report final.txt and report final.txt are different names (this was a review finding, see below).
• Headerless: reserve the floating button's footprint with a 28×24px float: inline-end ::before on the first line, so wrapped text flows around the corner. The lengths are the button's geometry, not tunables: the 28px sm IconButton inset spacing-2 ends 20px past the code's spacing-4 inline padding (+8px gap), and its bottom edge sits 36px − spacing-3 = 24px below the first line's top. Anchored on the line div rather than <code> because 100+-line blocks wrap lines in content-visibility chunks whose layout containment would keep an outer float from shortening their line boxes. Logical properties throughout, so RTL follows the button (inset-inline-end).

This mirrors the doctrine already recorded for markdown code blocks (styles.css: markdown always gives CodeBlock a structural header "instead of overlaying the horizontal scroll viewport") while keeping tool wells quiet — no added header chrome.

Verification

• Verified live against the packaged app via devtools on the reported well: title ellipsizes exactly at the button's edge (boundary 1031/1031, zero overlap); before/after screenshots above are from that app.
• An adversarial review pass (Codex) over the diff confirmed the geometry against the Astryx tokens (--size-element-sm, spacing-2/3/4), the header-class guard, RTL, consumer scope, and cascade order; its one P2 — nowrap collapsing literal spaces in path-like titles — is fixed in the third commit by keeping white-space: pre.
• npm run format:check clean.

Known trade-off: an ellipsized title's full value is no longer fully visible; it was not readable before either (hard clip + button overlap), it is excluded from the copy button's payload in both states (pickHeadline consumes it out of the body), and text selection still yields the full string. If the full headline should be hover-recoverable, a native title tooltip needs a small ToolCodeBlock component change — happy to follow up if preferred.

Co-Authored-By: Claude noreply@anthropic.com

https://claude.ai/code/session_01VqBZ8cP7wMpy1mXTrn3VDg