Why

PR #18431 exposed a Bazel clippy failure in the app-server unit-test target across Linux, macOS, and Windows. The failing lint was clippy::await_holding_invalid_type: two tracing tests serialized access to global tracing state by holding a tokio::sync::MutexGuard across awaited test work.

That serialization is still needed because the tests share process-global tracing setup and exporter state, but it should not require holding an async mutex guard through the whole test body.

What changed

• Replaced the bespoke async tracing_test_guard helper with serial_test on the two tracing tests that need global tracing serialization.
• Removed the #[expect(clippy::await_holding_invalid_type)] annotations and the lock guard callsites that Bazel clippy rejected.

Validation

• cargo test -p codex-app-server jsonrpc_span
• just fix -p codex-app-server
• git diff --check

I also attempted the exact failing Bazel clippy target locally with BuildBuddy disabled: bazel --noexperimental_remote_repo_contents_cache build --config=clippy --bes_backend= --remote_cache= --experimental_remote_downloader= -- //codex-rs/app-server:app-server-unit-tests-bin. That run did not reach clippy because Bazel timed out downloading libcap-2.27.tar.gz from kernel.org.