Field groups, tabs, actions and detected patterns

A manifest can group its fields under headings, carry a description body or a comment list behind a tab strip, offer actions that write back to the service, and name its own patterns to detect. Without these keys a manifest written for the other terminal degraded silently here — which is the real threat to "one manifest, many terminals". The six built-in manifests are now held key by key against that fork's copies, at a pinned commit — shefrd among them, a multiplexer pane address that becomes hoverable and opens the pane it names.

The manifest format is shared with a Windows Terminal fork, and the whole point of that is that one manifest works in both. That fork grew five keys; a manifest using them degraded silently here — a field group rendered as nothing, an action was ignored, a comment tab vanished — which is a far worse failure than a manifest being rejected, and a far bigger threat to the format than any cosmetic divergence.

fieldGroups gives named sets of display fields a heading on the card and a tri-state checkbox in settings; anything no group claims becomes an implicit unlabelled group shown first, so a manifest that groups only its secondary data still leads with its title. tabs carries a description body or a comment list behind a strip — Atlassian Document Format retains bold text, links, lists and code while converting to Markdown. Both body tabs and comment lists render that Markdown as data, never as executable HTML. actions is the only part of this subsystem that writes: a choice resolves its options from an earlier step, applies one, drops the cached preview and re-fetches so the badge updates in place. detectPatterns joins the scan pool as synthetic rules. Step optional records a failing step and steps over it.

• linkTooltip.integrations.<id>.enabled: false

  Whether this manifest is consulted at all.

• linkTooltip.integrations.<id>.fields: null

  Which display fields to show. null means the manifest's own list; [] means none.

• linkTooltip.integrations.<id>.settings: {}

  The manifest's own settings, seeded from each field's default.

• Undo is offered only when some other option leads back to where you were. Jira workflows are frequently one-directional, and the card says nothing rather than offering an undo that would fail.
• A failing optional step costs its section, not the card. Jira's Development panel and GitHub's richer endpoints are permission-dependent, and a 403 should not blank the preview.
• All four built-in manifests are held to the reference fork's copies key by key, at a pinned commit — so a key nobody thought to compare cannot drift. That checkout is somebody's live workspace whose HEAD moved four times during one session here; a test that reads its HEAD reports a different number every run, and parity stops being checkable.
• The divergences are a table in the test, and an entry is spent only when the key really differs — so one resolved upstream fails too, and asks for its entry back.

• The parity assertion had in fact been red for some time — nine failures, drift on three of the four manifests — which is the same shape as the thing it exists to catch: a ported feature degrading quietly while the note above it says it is fine.
• detectPatterns is often belt and braces here. Tabby's own URI detector already claims anything with a scheme://, so stith://… in plain output was hoverable before this. Measured, not assumed — two providers claim it, both as a link. It earns its keep on patterns that are not URIs.
• github.settings and github.matchers are deliberately not adopted. The repo#number matcher needs owner resolution that no manifest key expresses, and adopting the JSON without it would produce a 404 offered as a suggested rule.