macOS 26 menu bar extra is created but off-screen

### Summary

On macOS 26 (Tahoe), the client's menu bar extra is never inserted into the menu bar. The `NSStatusItem` is created successfully and is fully functional — it can be activated via the accessibility API — but it is placed at a fallback frame far below the visible screen area and is therefore never rendered.

This is not the "user removed the icon with Cmd+drag" case (#4860, #10027): no visibility preference was ever written, and the problem survives a full reinstall.

### Steps to reproduce

1. Run the client on macOS 26 with a configured account.
2. Observe the menu bar — no Nextcloud icon appears.
3. Query the item via the accessibility API (see below) — it exists, with a valid size, at an off-screen position.

### Expected behaviour

The status item is placed in the menu bar, like every other status item app.

### Actual behaviour

The status item is created but never attached to the menu bar.

Measured via System Events:

```
$ osascript -e 'tell application "System Events" to tell process "Nextcloud" \
to get {position, size} of every menu bar item of menu bar 2'
7, 981, 24, 24
```

Position `(7, 981)` on a 1512×982 logical display (built-in notched Retina display) puts the 24×24 item essentially below the bottom edge of the screen. Screenshots confirm nothing is drawn there — the item is simply not rendered anywhere.

For comparison, working status items on the same machine at the same moment:

| App | Position | Size |
|---|---|---|
| third-party app, Electron-based | (1164, 4) | 34×24 |
| third-party app, Electron-based | (1204, 4) | 24×24 |
| Apple system status item (native AppKit) | (1234, 4) | 73×24 |
| **Nextcloud (Qt)** | **(7, 981)** | **24×24** |

Both Electron-based items and the native AppKit one are placed correctly; only the Qt-based client is not. All were running simultaneously in the same session.

Notably, Control Center's own *hidden* status items sit at `(0, 982)` with size `0×0` — i.e. `y≈981/982` is the fallback position for an item that is not placed in the bar. The Nextcloud item has a real size but the same fallback origin.

### Ruled out

Each of these was verified individually on the affected machine:

- **Menu bar space / notch overflow** — ~258 pt of free space between the app menus (ending at x=906 right of the notch) and the leftmost status item (x=1164).
- **Menu bar manager** (Bartender, Ice, etc.) — none installed.
- **Visibility preferences** — no `NSStatusItem Visible` / `Preferred Position` key exists for the client, neither in the regular domain nor inside the sandbox container (`~/Library/Containers/com.nextcloud.desktopclient/Data/Library/Preferences/`). Note that `defaults find` does *not* cover container preferences, so earlier reports checking only the regular domain may have missed this.
- **Client configuration** — no tray-related key in `nextcloud.cfg`.
- **Auto-hiding menu bar** — `_HIHideMenuBar` and `AppleMenuBarVisibleInFullscreen` are unset; the menu bar is permanently visible (confirmed by screenshot).
- **Stale Control Center state** — `killall ControlCenter` does not change the position.
- **Item creation failure** — the FrontBoard scene is built without errors (see log excerpt).
- **Timing / autostart race** — a controlled cold start (SIGTERM, then `open -a Nextcloud`) reproduces the exact same position immediately. The item is misplaced from the first second; it does not drift later.

Since three other status item apps place correctly on the same system, this looks client-side rather than environmental.

### Log excerpt

The status item scene is requested and completed successfully — no error is logged:

```
[com.apple.BoardServices:XPCErrors] [C:2] Alloc com.apple.controlcenter.statusitems
[com.apple.FrontBoard:SceneExtension] Realizing settings extension __NSStatusItemSceneHostSettings__ on FBSSceneSettings
[com.apple.FrontBoard:Common] Requesting scene from com.apple.controlcenter.statusitems
[com.apple.FrontBoard:Common] Request for complete!
[com.apple.FrontBoard:SceneClient] […-Aux[1]-NSStatusItemView] Sending action(s) in update: NSSceneFenceAction
```

The `Aux[1]-NSStatusItemView` scene indicates a custom view is used for the status item rather than the modern `statusItem.button` API. Given that this is the one structural difference I could identify, it may be worth checking whether Qt's status item path still relies on the deprecated `NSStatusItem.view` property, which macOS has been progressively deprecating since 10.14.

### Workaround

The item is functional even though it is invisible, so the GUI can be reached via the accessibility API:

```bash
osascript -e 'tell application "System Events" to tell process "Nextcloud" \
to perform action "AXPress" of menu bar item 1 of menu bar 2'
```

This opens the settings window directly. Requires Automation and Accessibility permissions.

### Impact

Without this workaround the settings window, account management and the sync status are unreachable after the main window is closed — the client keeps syncing correctly, but is effectively headless. Related: #10227.

### Client version

34.0.1 (Qt 6.10.2). Also reproduced with 33.0.7 and earlier; survives reinstalls.

### Operating system

macOS 26.5.2 (build 25F84), Apple Silicon, built-in notched display only, no external monitor.

Start by tracing the Qt macOS status-item path and checking whether it uses the deprecated NSStatusItem.view property rather than the modern statusItem.button API. Reproduce on macOS 26 with a configured account and inspect the item's accessibility position; done when the Nextcloud item is visible in the menu bar and remains functional without the workaround.

Written by the indexing model from the issue text.