runner.rs Notify::Test / UrlScheme::Status / handle_url_open exits still bypass guard-flush

[bug-ops]

Description

Follow-up from #6696 (fixed via PR #6697). While fixing the guard-flush bypass for early_ctrlc and the 3 doctor/gonka/cocoon subcommand exits, the review chain (impl-critic) found 2 more sites directly inside run() and 5 sites inside handle_url_open sharing the exact same bug pattern — a bare std::process::exit that skips TracingGuards::drop's take-once-cell flush logic — but they were not named in #6696's scope and were intentionally left untouched.

Sites

• src/runner.rs:1186 (Notify::Test failure path) — directly inside run(), tracing_guards is in scope; trivial fix with the crate::tracing_init::exit_with_flush(tracing_guards, code) helper added in fix(tracing): flush guards on Ctrl-C and doctor-subcommand exit #6697.
• src/runner.rs:1231 (UrlScheme::Status --check stale-status path) — same, trivial fix with exit_with_flush.
• src/runner.rs:4482,4495,4514,4520,4547 inside fn handle_url_open (#[cfg(feature = "deep-link")]) — tracing_guards is alive on the caller's (run()) stack when handle_url_open is invoked, but handle_url_open is a separate function with no access to it. Fixing these requires either threading a flush handle into handle_url_open or returning an exit code up to run() instead of exiting internally — larger refactor than the other two groups, since it changes the function's control-flow shape.

Expected Behavior

The first two sites should be trivial to fix with the exit_with_flush helper already added in #6697 (near-zero marginal cost). The 5 handle_url_open sites need a small design decision (thread a flush handle through vs. return exit code to caller) before implementing.

Environment

• Version: unreleased (main, as of 2026-07-28), post-fix(tracing): flush guards on Ctrl-C and doctor-subcommand exit #6697 merge
• Relevant code: src/runner.rs (Notify::Test, UrlScheme::Status, handle_url_open), src/tracing_init.rs (exit_with_flush, take_and_flush_guard_cells)