[summeroff]

Problem: On Windows with CEF 6613, if a leftover obs64 still holds the profile's process-singleton lock, CefInitialize fails and CEF's teardown hits a use-after-free, crashing obs64 at startup (Sentry ContentMainRunnerImpl::Shutdown, 38 reports / 15 users since 1.22).

Change: Before CefInitialize, check <cache dir>\lockfile (held by Chromium with GENERIC_WRITE + FILE_SHARE_READ + DELETE_ON_CLOSE). Wait up to 3 s for the previous instance to release it; if still held, log an error and take the existing init-failure path. Companion: obs-studio-node now waits for the previous server to exit (separate PR).

Effect: Browser sources are disabled for that session instead of Desktop crashing.

Tests

• cmake --build build_x64 --config RelWithDebInfo --target obs-browser: builds
• clang-format 19.1.1 --dry-run -Werror: clean
• Harness: held lock reported held; released or stale lockfile reported free; check creates no file and doesn't block a later lock
• Not run: two-instance obs64 test with CEF 6613

[Copilot]

🔵 Needs a closer look

The harness does not exercise two obs64 instances on Windows with CEF 6613, leaving actual singleton-lock detection and crash-free timeout handling unverified.

No open issues 🎉

What changed in this PR

Adds a Windows-only cache-lock check before CEF initialization to avoid the reported startup crash when another process still holds the browser profile lock.

Changes:

• Probes the existing Chromium lockfile without creating a file, waiting up to three seconds for release.
• If the lock remains held or shutdown is requested during the wait, logs an error and takes the initialization-failure path, disabling browser sources for the session.

File	Description
obs-browser-plugin.cpp	Adds lock detection and bounded polling before CEF initialization on Windows.

_{Review effort: Balanced}