Desktop crashes (STATUS_BREAKPOINT 0x80000003) immediately after 'Isolating main process via DACL' on Windows 11 24H2 — regression on previously-working machine

## Summary

Desktop client crashes (`STATUS_BREAKPOINT 0x80000003`) immediately after the line `[NAPI] [INFO] desktop_core::process_isolation::process_isolation: Isolating main process via DACL`. The crash is reproducible across **every** version I downgraded to (2026.4.0, 2026.3.1, 2025.12.0). Window never appears; `Bitwarden.exe` exits within ~3 seconds of launch.

**Critical clue**: the same machine ran Bitwarden 2026.3.1 successfully for ~3 weeks before today's regression. The `app.log` starts on 2026-05-03 23:43:56 with the same `Isolating main process via DACL` line, after which startup completes normally (state v75, SignalR websocket connect, cipher decrypt). The crash regression began on 2026-05-27, but **the binary did not change** — only the system environment did. So something in Windows updated/installed/changed today (or in the last few days) is now interacting badly with `process_isolation`.

## Environment

- OS: Windows 11 Pro, Build 26200 (Version 10.0.26200, 24H2)
- CPU: Intel(R) Core(TM) i7-14700KF (Raptor Lake Refresh, has Intel CET / Shadow Stack)
- RAM: 64 GB
- Architecture: AMD64
- Bitwarden Desktop: tested 2026.4.0, 2026.3.1, 2025.12.0 — **all crash identically**
- Account type: cloud-hosted (vault.bitwarden.com)
- Defender real-time monitoring: enabled (no third-party AV)

## Reproduction

1. Launch `C:\Program Files\Bitwarden\Bitwarden.exe` (any of the versions above)
2. Process appears briefly in Task Manager (~3 seconds), no main window
3. `Application Error` event in Event Viewer:
```
Faulting application: Bitwarden.exe v2025.12.0.0
Exception code: 0x80000003 (STATUS_BREAKPOINT)
Timestamp: 0x68ed1081
```
4. Last lines in `%APPDATA%\Bitwarden\app.log`:
```
[2026-05-27 14:52:58.163] [info] [Process Isolation] Isolating process from debuggers and memory dumps
[2026-05-27 14:52:58.166] [info] [NAPI] [INFO] desktop_core::process_isolation::process_isolation: Isolating main process via DACL. pid=19632
```
No further log entries — process is killed via `__debugbreak()` (most likely) immediately after this NAPI call.

## What I tried (none helped)

| Attempted | Result |
|-----------|--------|
| Reinstall 2026.4.0 (latest stable) | Same crash |
| Downgrade to 2026.3.1 via official installer | Same crash |
| Downgrade further to 2025.12.0 | Same crash |
| Run as Administrator (`Start-Process -Verb RunAs`) | Same crash |
| Disable Windows mitigations on `Bitwarden.exe` via `Set-ProcessMitigation` (CFG, StrictCFG, UserShadowStack, UserShadowStackStrictMode, BlockDynamicCode, SEHOP, EnableRopStackPivot) — applied as SYSTEM via scheduled task | Same crash |
| Apply system proxy (`127.0.0.1:8118`) bypass for `*.bitwarden.com` | Same crash (problem isn't network) |

## Logs

- **Full `app.log`** (3858 lines, covers 2026-05-03 → 2026-05-27): https://gist.github.com/yanemet/a755ad8f43f908f5121f48d46f1b45d5
- **First successful startup** (2026-05-03 23:43:56, lines 1–30 of gist): Process Isolation runs, state v75 loads, login completes, SignalR connects to `wss://notifications.bitwarden.com/hub`
- **Final crash sequence** (2026-05-27 14:52:57, end of gist): Migrators all return `should migrate: false`, then `Isolating main process via DACL`, then nothing

## Working theory

The native Rust module `desktop_core::process_isolation` calls something (likely `SetKernelObjectSecurity` on the process handle to install a restrictive DACL), and this either:

1. Fails on Win11 24H2 build 26200 in some way that triggers an `assert!()` / `unwrap()` panic in the Rust code → process aborts via `__debugbreak()` → STATUS_BREAKPOINT
2. Succeeds in changing DACL but locks out something Electron's main-process needs next (GPU process spawn? renderer fork? IPC pipe?), and Electron's native bootstrap hits debug-break

A recent Windows update or third-party security software install between 2026-05-03 and 2026-05-27 likely changed the process security model in a way the `process_isolation` code didn't anticipate.

## Asks

1. Is there a documented way to **disable `process_isolation`** (env var, CLI flag, config file)? I couldn't find one in code search. Even a hidden one would unblock me while you investigate.
2. Could the `process_isolation` code log the actual return code from `SetKernelObjectSecurity` / equivalent Win32 call before claiming success, so future reports can pinpoint the actual failure?
3. Any guidance on which recent Windows updates / Defender ASR rules / GP policies might be in play here?

For now I'm using the browser extension as a workaround. Happy to provide additional logs, run debug builds, or attach Procmon / WPA traces if useful.

Start at the desktop_core::process_isolation::process_isolation entry point and review the final app.log sequence around “Isolating main process via DACL.” Reproduce on Windows 11 build 26200 and capture the native security-call outcome. Done means the regression trigger is identified or ruled out, with a documented mitigation or clear next step.

Written by the indexing model from the issue text.