A preview you can read, in a pane

A button on the card puts the same preview in a real pane beside the terminal — grouped fields, markdown bodies, comments, actions and a plugin's own HTML — with a switch that silences hover cards while one is open. One renderer component, mounted in two hosts, so the pane cannot end up less sealed than the card.

A hover card is the right size for a status and a title and the wrong size for a description, a comment thread, or a page that wanted eight hundred pixels. It also disappears the moment you move the pointer, which is the wrong behaviour for anything you actually want to read.

A button on the card opens the same preview in a real pane beside the terminal. linkPreviewView.component is the preview — groups, tab strip, markdown, comments, actions, the sandboxed frame — and the card and the pane each mount it. The only thing the pane passes that the card does not is room: a flag that swaps five CSS variables and a larger height cap for an html page, 4000px against the card's 320.

• linkTooltip.hideTooltipsWithPane: false

  Immediately follow hovered links in the source terminal's preview pane and suppress its hover cards. Other terminals are unaffected.

• This reverses a decision the fork had written down. htmlHost.ts used to say outright that "a plugin asking for 1000px does not get the pane", because there was no pane. Half of that still holds — the card is a hover affordance and stays clamped — and the comment now says which host each limit belongs to rather than stating a policy the code contradicts.
• A second copy of the markup is exactly how the pane would end up less sealed than the card, so the test asserts that no other template in the package contains an iframe at all.
• Suppression needs both halves — the setting and a pane actually open — which is what makes the switch safe to leave on: closing the last pane brings hover cards back without anyone having to remember.
• The pane takes the card's answers rather than resolving again. Asking a second time can get a different answer, because a text match has no link until an integration says so.
• Verified in a live window across 40 checks, including change-detection passes over an idle pane counted — measured 0 over 2.5s, because a runaway *ngFor does not fail a test, it hangs one.

• A pane is not restored with the window. It has no recovery token, which is upstream's own path for a tab that cannot be recovered — and that path leaves the container's ratios one entry long, an upstream bug affecting any such tab. Deliberate: a preview pane re-running someone's ticket fetch at boot is not worth it.