✨ feat(compact-tabs): open Set Window Title on name double-click

[kud]

📄 Description

#731 gives the window name a home beside the tabs, but once it's visible there's no way to change it from there — you still have to reach for the Window menu. That's an odd asymmetry: the name is right there, clickable-looking, and clicking it does nothing.

-hitTest: already hands the label the click naturally, because it's a subview sitting on top of the tab bar strip; #731 deliberately forwarded that hit back to _tabBarControl so the label wouldn't intercept drags and double-click-to-zoom. This keeps that forwarding for every other pixel of the strip but lets the name itself keep the hit, then adds a -mouseDown: that reads intent from click count: a double-click asks the delegate to open Set Window Title, anything else calls -performWindowDragWithEvent: — the same call the tab bar strip already relies on to act like a title bar. Because the double-click is spent on the title, the rest of the strip keeps zooming on double-click exactly as before; only the name itself changes behaviour.

Double-click rather than single-click is deliberate: a single click on a title bar is how you focus and drag a window, so spending it here would cost that. But the tension is worth stating plainly rather than glossing — elsewhere in iTerm2 a double-click on chrome consistently means zoom or maximise. On the tab bar it zooms the window; on a session title bar it maximises the pane (-sessionDoubleClickOnTitleBar: → -toggleMaximizeSession:). This change makes the window name the one place that gesture means something else. The case for it is that the name is a specific, labelled target rather than generic chrome, and that single-click is already spoken for — but if you would rather keep the double-click language uniform across the app, a context-menu item on the name is the obvious alternative and I am happy to switch. -menuForEvent: also now returns the tab bar's menu when the point is over the name, so taking the double-click doesn't cost the right-click menu that was there before.

Wiring is a single new delegate method, rootTerminalViewDidRequestEditWindowName, calling straight into the existing -editWindowTitle: action — no new UI, just a second way to reach the one that already exists on the Window menu. PSMTabBarControl stays untouched, as in #731.

🔍 Scope

Worth being explicit about one limitation: under the default showWindowNameBesideTabs setting ("When a custom name is set"), the label doesn't exist until a window already has a name, so this gesture can only ever rename a window — it's never how a window gets named the first time. The Window menu remains the only entry point for that.

✅ How to Validate

1. Theme: Minimal (or Compact). Window → Set Window Title, give it a name, open a second tab so the strip is showing.
2. Double-click the name — Set Window Title should open.
3. Single-click-and-drag the name — the window should still move.
4. Right-click the name — the tab bar's context menu should still appear.
5. Double-click elsewhere on the strip (not the name) — it should still zoom the window, unaffected.

🛠️ Developer Checklist

• Code is readable and maintainable
• Builds clean with no new warnings (tools/build.sh Development)
• Release notes updated in docs/notes-3.7.txt
• Manually verified end to end in the running Development build under Minimal — naming a window shows the label, double-clicking it opens Set Window Title, dragging still moves the window, right-click still opens the tab bar menu, and double-clicking elsewhere still zooms. Not exercised by hand: the Compact theme specifically, full screen, and non-top tab bar positions — all early-return via the same predicates ✨ feat(compact-tabs): show the window name beside the tabs in Compact and Minimal #731 already gates on, but untested here.
• Tests included and passing — there's no test coverage for tab bar mouse handling in this area, and none was added
• Commits follow Conventional Commits

[kud]

Dependency with another PR. I prefer to set it as a draft for now.