profiler: macOS desktop never samples its WebKit WebContent process #104

Summary

On macOS, the Profiler's process sampler never records the WebKit WebContent process that runs the BiBCode UI. A webview at 100 % CPU and 2.75 GB RSS therefore produces no process.sample row, no CPU finding and no memory finding. The only signs are indirect client.stall and rpc.slow findings. On Linux, the same webview (WebKitWebProcess) is a child of the desktop process and is sampled, as #96 shows.

Environment

Evidence

• 97f7ca61-5156 process.sample at 2026-10-14T19:13Z lists only two processes, desktop-host and helper (the crash monitor). At the same moment, ps showed the BiBCode WebContent process at about 100 % CPU and 2.75 GB RSS, with parent pid 1 (launchd). WebKit's XPC services are not children of the app.
• client.interaction: scrolling up a long chat timeline saturates the main thread #103 already notes "The WebContent process is not sampled" for a separate macOS incident.

Suspected source

• apps/server/src/diagnostics/profiler/sampler.rs:280-299: the sampler tracks itself, descendants_of(self_pid) and identities from ProcessAttributionRegistry. On macOS the WebContent process is neither a descendant nor registered.
• apps/server/src/diagnostics/profiler/sampler.rs:743: exe_kind already maps com.apple.webkit.webcontent to webview, so the data path exists and only discovery is missing.
• apps/desktop/src-tauri/src/backend/ui_process_observer/macos.rs:156-169: the desktop already resolves the WebContent pid through _webProcessIdentifier, but that result feeds only apps/server/src/diagnostics/resource_sampler.rs (process diagnostics), not the Profiler.

Reproduction

1. Turn on the Profiler in the macOS desktop app.
2. Run profiler events --kind process.sample --limit 1 --json.
3. Compare with ps -axo pid,ppid,comm | grep WebKit.WebContent: the BiBCode WebContent process (started together with bibcode-desktop) is missing from the sample.

Root-cause hypothesis

Profiler discovery walks the process tree, and macOS launches WebKit's processes as XPC services under launchd. Confidence: high, because the sampler code walks only descendants and registered identities, and the sample shows exactly those.

Suggested fix direction

Register the WebContent (and optionally GPU) pid that the macOS UI-process observer already finds with ProcessAttributionRegistry::register_identity as a webview identity, refresh it when WebKit replaces the process, and let raises_findings("webview") apply. Also check Windows WebView2, whose processes may also sit outside the host's tree.