The hover card stays inside the pane

Clamping where an edge lands does nothing once the card is already wider than the pane it floats over. The width cap is now the lesser of the setting and the hovered screen's own width, written before the card is measured rather than after.

The hover card knew about the window and not about the pane it was floating over. In a narrow split it rendered past the pane's edge — worst exactly where you most need to read it.

position() writes --link-card-max-width, the lesser of linkTooltip.maxWidth and the hovered .xterm-screen's own width, before it reads the card's size. Clamping where an edge lands does nothing once the card is already wider than the pane. The setting is an upper bound, never the width.

• CSS applies min-width after max-width, so the cap has to be spelled into both — or the card's 220px minimum quietly wins back the overflow in a narrow split.
• The card is position: fixed but a DOM child of .xterm-screen: it has to be a descendant or xterm's hover guard never applies and mouseleave clears the link the instant the pointer reaches the card, and it has to be fixed or the pane's overflow: hidden clips it. The fixed containing block is not always the window, so it is placed by measuring its own origin at translate(0,0) and then translating.

• The source catalogue records no separate caveats for this entry. The implementation and evidence above define its scope.