Replace parking_lot Mutex with tokio Mutex to align with kona-node async primitives - #433

Motivation

• parking_lot::Mutex is incompatible with certain concurrency primitives used by kona-node.
• We need an async-aware mutex that cooperates with the Tokio scheduler and avoids blocking the runtime.

Change summary

• Replace parking_lot::Mutex on async code paths with tokio::sync::Mutex.
• Update all call sites to lock().await and adjust signatures to be async where necessary.
• Keep tests and pure-sync helpers on std::sync::Mutex.

Scope

• Updated modules: server, health, probe, debug_api (runtime paths) now use tokio::sync::Mutex.
• Test and harness code (e.g., request trackers, port allocators) use std::sync::Mutex.
• Minor refactors around call-sites to make locking async-safe and avoid .await inside non-async contexts.

Incidental behavior adjustments (in service of the migration)

• Execution-mode handling and health checks were tightened to ensure locks are taken asynchronously and health state updates are non-blocking.
• Builder calls (e.g., FCU/newPayload) are gated consistently behind execution mode and health, ensuring we don’t hold sync locks across awaits.

Testing and verification

• Updated unit/integration tests to use std::sync::Mutex for mock state.
• Assertions and harnesses adjusted to reflect non-blocking health updates and builder gating.
• No external API shape changes; endpoints retain existing request/response formats.

Risk and rollout

• Touches synchronization across core request paths; requires careful soak in staging.
• Look for deadlock regressions, starvation, or unexpected latency under load.

Follow-ups

• Audit remaining modules (e.g., flashblocks/inbound.rs) for any lingering parking_lot::Mutex on async paths and migrate to tokio::sync::Mutex where applicable.