🐛 fix(tab-groups): inherit window appearance in group menu and name dialog

[kud]

Note

Draft on purpose: I haven't compiled this locally yet, so treat it as a proposal on shape rather than something to pull. I'll build and confirm the behaviour before marking it ready for review.

📄 Description

The tab group UI added in the recent tab-groups work doesn't inherit the window's appearance, so on a dark window the group context menu and the group name dialog both render in the light system appearance. The per-tab equivalents already handle this.

Two omissions, each fixed by applying the precedent that already exists a few hundred lines away in the same file:

Site	Symptom	Precedent copied from
-tabView:menuForTabGroup:	Right-clicking a group header gives a light menu on a dark window	-tabView:menuForTabViewItem: (PseudoTerminal.m:7975)
-promptForTabGroupName:title:	"New Tab Group" and "Rename Tab Group" dialogs are light on a dark window	-openEditTabTitleWindow (PseudoTerminal.m:8375)

Two notes on why it's a copy rather than a shared helper:

• The two blocks are deliberately not interchangeable. The menu path keys off it_terminalWindowUseMinimalStyle and the decoration background's perceived brightness; the alert path keys off kPreferenceKeyTabStyle == TAB_STYLE_MINIMAL and minimalTabStyleBackgroundColor.isDark. Same intent, different predicates, and swapping them would change behaviour under Compact and Automatic. Each site copies its own matching precedent.
• That does leave the blocks duplicated a further two times. Consolidating them into one helper is a worthwhile tidy, but it touches unrelated call sites, so I've kept it out of this PR rather than bundling a refactor with a visual fix. Happy to follow up with it separately if you'd like.

-promptForTabGroupName:title: is shared by both "New Tab Group" (-addTabToNewGroup:) and "Rename Tab Group" (-renameTabGroupWithID:), so the single insertion covers both dialogs.

The colour swatch view (ColorsMenuItemView) inserted into the group menu is a custom-drawn subview, so setting the menu's appearance should cover it without a separate change. That's the one part I want to confirm visually rather than assert.

🔍 Scope

Out of scope, flagged rather than fixed:

• WindowArrangements.m:296 — the replace-confirmation alert sets no appearance either, but it predates tab groups and is shared with "Save Window as Arrangement".
• -closeTabs:confirmWith:skippingPinned: is fine already; it routes through iTermWarning with window:self.window, so it's a sheet on the window.

✅ How to Validate

1. Use a dark theme (or a dark background colour with Minimal style)
2. Create a tab group
3. Right-click the group header — the menu should be dark, matching the per-tab context menu
4. Choose Rename Group — the dialog should be dark
5. Right-click a tab → Add to New Group — that dialog should be dark too
6. Repeat on a light theme and confirm nothing regressed
7. Worth an extra look: the colour swatches in the group menu should tint correctly under the dark appearance

🛠️ Developer Checklist

• Code is readable and maintainable
• Single atomic commit
• Tests included and passing (if applicable) — no test coverage for appearance wiring in this area
• Commits follow Conventional Commits

[gnachman]

This looks good to me. Both hunks are faithful copies of the precedents you cited (the per-tab menu and the tab-title dialog), every symbol they use is already in scope in that file, and neither touches a return contract or call site. It closes a real gap: the tab-group menu and name dialog genuinely don't inherit the window appearance on master today.

Do you have any reservations before marking it ready? In particular, were you able to confirm the build and take a look at the color swatches under the dark appearance that you flagged?