[Bug]: macOS Secure Input remains active after Orca loses focus and quits

### Operating system

macOS 26.5.2 (Build 25F84, Apple Silicon)

### Orca version

1.4.194. The same focus-loss pattern was also observed on 1.4.190.

### Details

#### Short summary

Orca can leave macOS Secure Event Input enabled after the Orca window loses focus and even after Orca quits. While this state is active, Option-only global shortcuts registered by other applications stop working system-wide.

During a live reproduction on Orca 1.4.194, both Raycast diagnostics and IORegistry identified the live Orca process as the Secure Input owner. After Orca was quit and restarted, Secure Input remained enabled and IORegistry continued to point to the old, now-dead Orca PID.

#### User impact

- All global shortcuts made from Option plus a regular key stop firing.
- For example, Option plus number keys type normal macOS alternate characters instead of invoking the configured command.
- Shortcuts that include Control plus Option continue working.
- The behavior affects both the built-in Mac keyboard and an external keyboard.
- Raycast still reports all 41 command hotkeys as successfully registered with zero registration failures, but the Option-only shortcuts are not delivered.

#### Live reproduction on 1.4.194

The exact trigger is not yet deterministic, but this sequence occurred during normal Orca use:

1. Orca was running with multiple agent terminal panes and one client-hosted Browser tab.
2. The Mac entered sleep and later woke.
3. Secure Input toggled several times after wake, then remained enabled.
4. Switching from the Browser workspace to an ordinary Orca terminal pane did not release it.
5. Making Finder the frontmost application did not release it.
6. Closing the only Orca Browser tab did not release it.
7. Quitting and restarting Orca did not release it.

Privacy-safe timeline:

```text
14:45:07 macOS / Raycast: willSleep
14:48:32 macOS / Raycast: didWake
14:48:52.761 Secure Input state changed: Active=true
14:48:52.762 Captured owner bundle: com.stablyai.orca
Orca PID: 5329
14:53:04.507 Secure Input remained active after owner app lost focus
Owner: com.stablyai.orca, PID 5329
Frontmost app: Finder
```

After restarting Orca:

```text
Old Orca PID: 5329 (no longer exists)
New Orca PID: 98801
IsSecureEventInputEnabled(): true
kCGSSessionSecureInputPID: 5329
```

This means the new Orca process cannot release the state associated with the old process or connection.

The state was checked with:

```sh
ioreg -l -w 0 | grep SecureInput
ps -p
```

and with the public Carbon `IsSecureEventInputEnabled()` API.

#### Earlier observation on 1.4.190

A previous Raycast log captured the same Orca focus-loss pattern:

```text
10:31:42.370 Secure Input changed to Active=true
10:31:42.371 Owner bundle: com.stablyai.orca
10:31:43.445 Warning: Secure Input remained active after Orca lost focus
10:35:23.747 Secure Input changed to Active=false
```

The observed lower bound was approximately 3 minutes 41 seconds. Orca remained alive and eventually released the state in that occurrence.

#### Relevant Orca and Chromium behavior

Orca does not appear to call Electron `app.setSecureKeyboardEntryEnabled` explicitly. However, Orca 1.4.190 source contains several password inputs that Chromium handles automatically:

- `SshPassphraseDialog` focuses its password input with `requestAnimationFrame(... input.focus())`.
- The Linear API-key dialog auto-focuses a password input.
- The Bitbucket access-token dialog auto-focuses a password input.
- Other settings and credential surfaces also contain password inputs.

Chromium uses a process-level `ScopedPasswordInputEnabler` counter for focused password inputs. The password input enabler should be reset when the view loses focus or the window stops being key. The observed behavior is consistent with a password or credential surface incrementing that counter without the corresponding focus or lifecycle path decrementing it.

The current embedded Browser page had no password input and `document.activeElement` was `BODY` when inspected. Closing that Browser tab did not clear Secure Input, so the current evidence points more toward the main renderer, a hidden or already-unmounted credential dialog, or a sleep/wake focus restoration path.

Version matrix:

- Orca 1.4.190: Electron 43.1.0, Chromium 150.0.7871.47
- Orca 1.4.194: Electron 43.4.1, Chromium 150.0.7871.224

Chromium `ui/base/cocoa/secure_password_input.mm` is identical between those two Chromium patch versions, and the relevant `RenderWidgetHostViewMac` password focus/reset logic is unchanged.

#### Related Orca issues

- #12017 reported that global macOS Option shortcuts such as Option+1, Option+2, and Option+C stopped working while Orca was active. The reporter later considered it a false positive after restarting Aerospace, so it was closed without a root-cause investigation.
- #8490 documented that `SshPassphraseDialog` could mount behind another surface while its password input still received focus invisibly. That issue fixed the visual stacking problem, not Secure Input lifecycle handling.

I found no existing public Orca issue or discussion that covers Secure Input remaining active after Orca loses focus or exits.

#### Expected behavior

- Orca should release Secure Input when a password input loses focus, its dialog unmounts, the window resigns key status, the app sleeps, or the app quits.
- Restarting Orca should not leave macOS pointing at a dead Orca PID as the Secure Input owner.
- Hidden or background password inputs should not keep Secure Input active indefinitely.

#### Actual behavior

Secure Input can remain active while Orca is unfocused and can survive termination of the Orca process, leaving Option-only global shortcuts broken until the macOS GUI session is reset.

#### Areas worth investigating

- Password-input focus cleanup during app deactivation and sleep/wake.
- `SshPassphraseDialog` and other auto-focused credential dialogs during hidden, dismissed, or restored UI states.
- Main-renderer and Browser guest teardown paths.
- Instrumentation around password-input mount, focus, blur, unmount, window key changes, sleep, and wake.
- A warning in Orca when Secure Input remains enabled after Orca loses focus.

The IORegistry owner PID is known to be best-effort on macOS, so attribution should be treated carefully. However, the same Orca focus-loss pattern was observed twice, and the current reproduction pointed to a live Orca PID before continuing to point to that exact dead PID after Orca restarted.

I can provide additional privacy-redacted Raycast and Orca trace excerpts if needed.

Start by tracing SshPassphraseDialog and the other auto-focused credential dialogs through focus, dismissal, unmount, app deactivation, and sleep/wake paths. Then inspect main-renderer and Browser guest teardown behavior and the Chromium secure password-input handling described in the issue. Done means Secure Input is released on these lifecycle transitions and the reported stale-owner behavior is reproduced and prevented.

Written by the indexing model from the issue text.