The card says which rule matched

A line on the hover card naming the rule that produced it — or saying that none did and the defaults applied, which is the answer to "why is this link not previewed the way I set it up". Clicking it opens that rule in the settings. The button row also stops being pinned to the card's bottom edge and instead picks an edge named relative to the link, since the card flips above the line when there is no room below.

The card has always known which rule produced it — EffectiveTooltipSettings has carried the rule since rules existed — and threw it away. So "why is this link not previewed the way I set it up" had no answer anywhere in the interface. Separately, the button row was pinned to the card's bottom edge, and the card flips above the hovered line when there is no room below — so "bottom" was the edge next to the link half the time and the edge furthest from it the rest, depending on where in the pane you happened to be pointing.

With linkTooltip.showRuleAttribution on, the card carries a line on its far edge naming the rule, and clicking it opens that rule in the settings. linkTooltip.actionsPlacement names the button edge relative to the link — 'Next to the link' or 'Far edge' — resolved after the card has been measured and flipped.

• linkTooltip.showRuleAttribution: false

  Diagnostic, so off by default.

• linkTooltip.actionsPlacement: 'far'

  What the old always-bottom behaviour produced in the common case.

• linkTooltip.showCustomActions: true

  Split out of showButtons, which used to delete rule-authored buttons too.

• Three states, not two. A synthetic rule built from an integration's detectPatterns is a real rule in the matching pool but is in nobody's rule list, so it reads Detected by the X integration with nothing to open — calling it "no rule matched" would be untrue.
• The rule is found by identity, which is exact: hydrateRule completes a stored rule in place and the list is memoised, so the object the matcher returned is the object the settings page edits.
• Opening resolves index first with the name as a check, and failing both lands on the rules list rather than on whatever rule has since moved into that slot.
• Resolving placement after measuring is safe because it is CSS order over the same children — the card is exactly as tall either way, which the test asserts.

• "No rule matched" is the useful half and the one worth switching this on for; naming a rule you already know about is the lesser half.
• The showButtons split is a real behaviour change: someone who had it off and custom actions on a rule will see those actions again.