The Link Tooltip page is grouped

A 500-line flat scroll becomes four collapsible groups that remember what was open across saves and navigation. Two rows stay outside every group because nothing on the page governs them, and one setting gets a group of its own rather than being greyed out by a switch that does not actually apply to it.

The Link Tooltip page had grown to a five-hundred-line flat scroll under four static headings, with everything visible at once whether it applied or not.

Four collapsible groups — Hover card, Buttons, Clicking, Integration previews — that remember what was open across saving and navigating away. Two rows stay outside every group.

• A setting only goes under a master switch that really governs it. "Let integrations draw their own tooltip" sits with the card settings and looks like it belongs there, but it governs the preview pane too, which outlives the card — under the card's switch it would be greyed out while still applying. It gets a group of its own.
• Link detection and the safe-scheme list stay ungrouped: detection continues when the card is off, and safe schemes apply to every path that opens a link, not just to the card.
• Nothing sets disabled on a group. That disables the group's own header, and every master switch lives inside the group it governs — so a disabled group could never be opened to switch it back on. The gating is per-row.
• Group state is view state, so it lives in localStorage rather than config.yaml, in the same shape the profile tree already uses.

• A collapsed group's body has never been instantiated, so its controls are not merely hidden — they are absent from the page. Tabby has no settings search, so nothing needs to reach into them; a build that grew one would need to open the group first.
• An id the stored map does not mention falls back to that group's intended default rather than to "open", so a group added later starts where it was meant to.