OpenCLIApp 0.1.31 launches but shows a blank black window on macOS 27.0

Nobody has claimed this yet.

### Summary

OpenCLIApp 0.1.31 launches on macOS 27.0, but the desktop GUI is not usable: the process starts and native windows are created, yet the visible app window renders as an empty black window.

This looks related to or a newer-system reproduction of #1990, but I am filing a separate report because the local environment is macOS 27.0 / WebKit 623.1.14 and the installed app version is 0.1.31.

### Environment

- macOS: 27.0
- Build: 26A5368g
- OpenCLIApp: 0.1.31
- Bundle id: `com.opencli.browserbridge`
- CLI runtime: `opencli v1.8.4`
- Node bundled with app: `v24.16.0`
- GitHub CLI account used to file this issue: `DoTheWorkNow`

### What Works

The CLI/daemon side appears healthy:

```text
opencli v1.8.4 doctor (node v24.16.0)

[OK] Daemon: running on port 19825 (v1.8.4)
[OK] Extension: connected (v1.0.20)

Profiles:
• azznq6wp: connected v1.0.20
[OK] Connectivity: connected in 0.1s

Everything looks good!
```

Gatekeeper/signing also look fine:

```text
/Applications/OpenCLIApp.app: valid on disk
/Applications/OpenCLIApp.app: satisfies its Designated Requirement

/Applications/OpenCLIApp.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: jie wen (FABM2QUA8Q)
```

### What Fails

Launching the app from Finder/Dock or with:

```bash
open /Applications/OpenCLIApp.app
```

starts the process:

```text
/Applications/OpenCLIApp.app/Contents/MacOS/opencli-app
```

However, System Events reports no visible/accessible app window:

```text
visible=false, frontmost=false, windows=0
```

CoreGraphics does see native windows owned by the process, for example:

```text
id=11437 layer=0 name=OpenCLIApp bounds={ Height = 680; Width = 980; X = 266; Y = 85; }
id=11436 layer=5 name=OpenCLIApp bounds={ Height = 500; Width = 380; X = 566; Y = 130; }
```

Capturing the 980x680 window shows only a blank/black window with the standard macOS traffic-light buttons and no rendered UI.

### Relevant Logs

Filtered logs for `opencli-app` and its WebContent processes show WebKit/WebContent sandbox and layer-suspension failures:

```text
WebContent[...] Connection init failed at lookup with error 159 - Sandbox restriction
WebContent[...] Failed to set up CFPasteboardRef 'Apple CFPasteboard general'
WebContent[...] Failed to look up the port for "com.apple.windowserver.active" (1)
WebContent[...] TCCAccessRequest_block_invoke: Connection invalid
WebContent[...] networkd_settings_read_from_file_locked Sandbox is preventing this process from reading networkd settings file at "/Library/Preferences/com.apple.networkd.plist"
WebContent[...] WebPage::markLayersVolatile: Failed to mark all layers as volatile, will retry
WebContent[...] WebPage::markLayersVolatile: Failed to mark layers as volatile within 2000ms
WebContent[...] WebProcess::markAllLayersVolatile: Failed to mark layers as volatile
```

### Package Observations

The installed app binary appears to be a Tauri/Wry desktop shell:

```text
tauri 2.11.2
wry 0.55.1
tao 0.35.3
tauri-plugin-updater 2.10.1
```

The app links against:

```text
AppKit.framework
WebKit.framework
Carbon.framework
```

`Info.plist` contains:

```text
LSRequiresCarbon => true
```

I tested a copied app bundle with `LSRequiresCarbon` removed and ad-hoc re-signed. That did **not** fix the black window, so this key is probably not the only cause, but it still looks suspicious for a modern Tauri app.

Also, `codesign -d --entitlements :- /Applications/OpenCLIApp.app` prints no entitlements payload beyond the executable line, so the app may not be declaring macOS entitlements that are commonly needed by WebView/Tauri apps.

### Expected Behavior

The OpenCLIApp desktop window should render the normal UI and be visible/focusable after launch.

### Actual Behavior

The app process starts, CLI/daemon remains healthy, native windows are created, but the GUI window stays blank/black and is not exposed as a normal visible window through System Events.

### Possible Direction

This may need a desktop-shell fix rather than a CLI reinstall:

- verify macOS 27 / WebKit 623 compatibility with current `tauri/wry/tao` versions
- remove `LSRequiresCarbon` from generated `Info.plist`
- review macOS entitlements for the Tauri/WebKit shell
- ensure the main window is explicitly shown/focused and not treated as only a tray/popover/background window
- add startup renderer diagnostics or a fallback/error screen so WebView initialization failures do not appear as a silent black window

Reproduce the launch with `open /Applications/OpenCLIApp.app`, then inspect the generated `Info.plist`, the `opencli-app` bundle, and the reported WebKit/WebContent logs on macOS 27. Compare the Tauri desktop-shell startup behavior with the window visibility and renderer diagnostics; done means the normal UI renders in a visible, focusable window instead of a blank black one.

Written by the indexing model from the issue text.