Closes #33018

### Problem

When opening a `PopoverMenu` or `RightClickMenu`, the pane's tab bar
buttons would flicker (disappear for a couple frames then reappear).
This happened because:

1. The menu is created and `window.focus()` was called immediately
2. However, menus are rendered using `deferred()`, so their focus
handles aren't connected in the dispatch tree until after the deferred
draw callback runs
3. When the pane checks `has_focus()`, it calls `contains_focused()`
which walks up the focus hierarchy — but the menu's focus handle isn't
linked yet
4. `has_focus()` returns false → tab bar buttons disappear
5. Next frame, the menu is rendered and linked → `has_focus()` returns
true → buttons reappear

### Solution

Delay the focus transfer by 2 frames using nested `on_next_frame()`
calls before focusing the menu.

**Why 2 frames instead of 1?**

The frame lifecycle in GPUI runs `next_frame_callbacks` BEFORE `draw()`:

```
on_request_frame:
  1. Run next_frame_callbacks
  2. window.draw()  ← menu rendered here via deferred()
  3. Present
```

So:
- **Frame 1**: First `on_next_frame` callback runs, queues second
callback. Then `draw()` renders the menu and connects its focus handle
to the dispatch tree.
- **Frame 2**: Second `on_next_frame` callback runs and focuses the
menu. Now the focus handle is connected (from Frame 1's draw), so
`contains_focused()` returns true.

With only 1 frame, the focus would happen BEFORE `draw()`, when the
menu's focus handle isn't connected yet.

This follows the same pattern established in b709996 which fixed the
identical issue for the editor's `MouseContextMenu`.

Closes #33018

### Problem

When opening a `PopoverMenu` or `RightClickMenu`, the pane's tab bar
buttons would flicker (disappear for a couple frames then reappear).
This happened because:

1. The menu is created and `window.focus()` was called immediately
2. However, menus are rendered using `deferred()`, so their focus
handles aren't connected in the dispatch tree until after the deferred
draw callback runs
3. When the pane checks `has_focus()`, it calls `contains_focused()`
which walks up the focus hierarchy — but the menu's focus handle isn't
linked yet
4. `has_focus()` returns false → tab bar buttons disappear
5. Next frame, the menu is rendered and linked → `has_focus()` returns
true → buttons reappear

### Solution

Delay the focus transfer by 2 frames using nested `on_next_frame()`
calls before focusing the menu.

**Why 2 frames instead of 1?**

The frame lifecycle in GPUI runs `next_frame_callbacks` BEFORE `draw()`:

```
on_request_frame:
  1. Run next_frame_callbacks
  2. window.draw()  ← menu rendered here via deferred()
  3. Present
```

So:
- **Frame 1**: First `on_next_frame` callback runs, queues second
callback. Then `draw()` renders the menu and connects its focus handle
to the dispatch tree.
- **Frame 2**: Second `on_next_frame` callback runs and focuses the
menu. Now the focus handle is connected (from Frame 1's draw), so
`contains_focused()` returns true.

With only 1 frame, the focus would happen BEFORE `draw()`, when the
menu's focus handle isn't connected yet.

This follows the same pattern established in b709996 which fixed the
identical issue for the editor's `MouseContextMenu`.

Closes zed-industries#33018

### Problem

When opening a `PopoverMenu` or `RightClickMenu`, the pane's tab bar
buttons would flicker (disappear for a couple frames then reappear).
This happened because:

1. The menu is created and `window.focus()` was called immediately
2. However, menus are rendered using `deferred()`, so their focus
handles aren't connected in the dispatch tree until after the deferred
draw callback runs
3. When the pane checks `has_focus()`, it calls `contains_focused()`
which walks up the focus hierarchy — but the menu's focus handle isn't
linked yet
4. `has_focus()` returns false → tab bar buttons disappear
5. Next frame, the menu is rendered and linked → `has_focus()` returns
true → buttons reappear

### Solution

Delay the focus transfer by 2 frames using nested `on_next_frame()`
calls before focusing the menu.

**Why 2 frames instead of 1?**

The frame lifecycle in GPUI runs `next_frame_callbacks` BEFORE `draw()`:

```
on_request_frame:
  1. Run next_frame_callbacks
  2. window.draw()  ← menu rendered here via deferred()
  3. Present
```

So:
- **Frame 1**: First `on_next_frame` callback runs, queues second
callback. Then `draw()` renders the menu and connects its focus handle
to the dispatch tree.
- **Frame 2**: Second `on_next_frame` callback runs and focuses the
menu. Now the focus handle is connected (from Frame 1's draw), so
`contains_focused()` returns true.

With only 1 frame, the focus would happen BEFORE `draw()`, when the
menu's focus handle isn't connected yet.

This follows the same pattern established in b709996 which fixed the
identical issue for the editor's `MouseContextMenu`.

Closes zed-industries#33018

### Problem

When opening a `PopoverMenu` or `RightClickMenu`, the pane's tab bar
buttons would flicker (disappear for a couple frames then reappear).
This happened because:

1. The menu is created and `window.focus()` was called immediately
2. However, menus are rendered using `deferred()`, so their focus
handles aren't connected in the dispatch tree until after the deferred
draw callback runs
3. When the pane checks `has_focus()`, it calls `contains_focused()`
which walks up the focus hierarchy — but the menu's focus handle isn't
linked yet
4. `has_focus()` returns false → tab bar buttons disappear
5. Next frame, the menu is rendered and linked → `has_focus()` returns
true → buttons reappear

### Solution

Delay the focus transfer by 2 frames using nested `on_next_frame()`
calls before focusing the menu.

**Why 2 frames instead of 1?**

The frame lifecycle in GPUI runs `next_frame_callbacks` BEFORE `draw()`:

```
on_request_frame:
  1. Run next_frame_callbacks
  2. window.draw()  ← menu rendered here via deferred()
  3. Present
```

So:
- **Frame 1**: First `on_next_frame` callback runs, queues second
callback. Then `draw()` renders the menu and connects its focus handle
to the dispatch tree.
- **Frame 2**: Second `on_next_frame` callback runs and focuses the
menu. Now the focus handle is connected (from Frame 1's draw), so
`contains_focused()` returns true.

With only 1 frame, the focus would happen BEFORE `draw()`, when the
menu's focus handle isn't connected yet.

This follows the same pattern established in b709996 which fixed the
identical issue for the editor's `MouseContextMenu`.

Closes zed-industries#33018

### Problem

When opening a `PopoverMenu` or `RightClickMenu`, the pane's tab bar
buttons would flicker (disappear for a couple frames then reappear).
This happened because:

1. The menu is created and `window.focus()` was called immediately
2. However, menus are rendered using `deferred()`, so their focus
handles aren't connected in the dispatch tree until after the deferred
draw callback runs
3. When the pane checks `has_focus()`, it calls `contains_focused()`
which walks up the focus hierarchy — but the menu's focus handle isn't
linked yet
4. `has_focus()` returns false → tab bar buttons disappear
5. Next frame, the menu is rendered and linked → `has_focus()` returns
true → buttons reappear

### Solution

Delay the focus transfer by 2 frames using nested `on_next_frame()`
calls before focusing the menu.

**Why 2 frames instead of 1?**

The frame lifecycle in GPUI runs `next_frame_callbacks` BEFORE `draw()`:

```
on_request_frame:
  1. Run next_frame_callbacks
  2. window.draw()  ← menu rendered here via deferred()
  3. Present
```

So:
- **Frame 1**: First `on_next_frame` callback runs, queues second
callback. Then `draw()` renders the menu and connects its focus handle
to the dispatch tree.
- **Frame 2**: Second `on_next_frame` callback runs and focuses the
menu. Now the focus handle is connected (from Frame 1's draw), so
`contains_focused()` returns true.

With only 1 frame, the focus would happen BEFORE `draw()`, when the
menu's focus handle isn't connected yet.

This follows the same pattern established in b709996 which fixed the
identical issue for the editor's `MouseContextMenu`.