Fix (high): serialize runtime creation under the per-app operation lock

[Rigidity]

Severity: High (H7)

Problem

create_runtime resolved the app via resolve_app — which acquires the per-app operation lock and returns it inside ResolvedStoppedApp — and then immediately dropped that guard with stopped.into_app() before rotating storage, calling write_runtime, and creating the child webview.

Consequences:

• Two concurrent apps_start_user_app calls for the same app can both observe it as stopped and both proceed, producing duplicate runtimes (both maps get overwritten with no "already exists" check).
• write_runtime records a "running" runtime before the webview exists, so a concurrent resolve_app returns Running for an app whose webview lookup then fails (a "phantom" runtime).

Fix

Add ResolvedStoppedApp::into_app_and_guard() and keep the operation guard held through the entire create/rotate/webview sequence in create_runtime_for_app (passed as an Option<OwnedMutexGuard<()>>). A second concurrent start now blocks in resolve_app until the first finishes and then observes the completed runtime instead of creating a duplicate. Internal/origin-cleanup starts that don't go through resolve_app pass None.

Files

• crates/sage-apps/src/runtime/start.rs
• crates/sage-apps/src/types/app/user_apps.rs

Follow-up (not in this PR)

The related clear-data race the review notes — resolve_stopped_app releases the op lock between its close-and-retry attempts, so a concurrent start can interleave with apps_clear_runtime_browsing_data after rotation — is a separate change to the retry/close protocol and is left for a focused follow-up.

No local build (per request); relying on CI.

---

Note

Medium Risk
Touches core app runtime lifecycle and concurrency; scope is narrow and behavior-preserving aside from fixing races, but incorrect locking could still affect startup reliability.

Overview
Serializes user-app runtime startup by keeping the per-app operation mutex from resolve_app until the webview is created, instead of dropping it when extracting the stopped app.

create_runtime now uses into_app_and_guard() and passes that guard into create_runtime_for_app as an optional _op_guard held for the full rotate → write_runtime → child webview path. Concurrent starts for the same app block on the lock; the second caller should see an already-running runtime rather than spawning duplicates or a phantom runtime recorded before the webview exists.

Internal paths that skip resolve_app (e.g. origin cleanup) pass None for the guard.

^{Reviewed by Cursor Bugbot for commit b288068. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Hadamcik]

Fixed: 817e902