fix(clippy): replace std::sync::Mutex with tokio::sync::Mutex in test

[github-actions]

What clippy found

clippy::await_holding_lock fired on a test in src/compile/source_path_guard.rs:

error: this `MutexGuard` is held across an await point
   --> src/compile/source_path_guard.rs:295:13
    |
295 |         let _guard = CWD_LOCK.lock().unwrap();
    |             ^^^^^^
note: these are all the await points this lock is held through
   --> src/compile/source_path_guard.rs:299:73
    |
299 |         let result = validate_workflow_source_path("workflows/evil.md").await;

The static CWD_LOCK was a std::sync::Mutex, and its guard was held across .await. Tokio can move a task to a different thread after an await resumes, so holding a std::sync::Mutex guard across an await point is a potential deadlock.

How it was fixed

Lint: clippy::await_holding_lock
File: src/compile/source_path_guard.rs
Fix: Changed the static from std::sync::Mutex::new(()) to tokio::sync::Mutex::const_new(()) (which is const-constructible for use in a static) and changed the lock call from .lock().unwrap() to .lock().await. The tokio::sync::Mutex is designed to be held across await points.

Verification

• cargo build --all-targets ✅
• cargo test ✅ (all tests pass)
• cargo clippy --all-targets --all-features --workspace -- -D warnings ✅ (clean)

Warning

Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

• spsprodeus21.vssps.visualstudio.com
• spsprodweu4.vssps.visualstudio.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "spsprodeus21.vssps.visualstudio.com"
    - "spsprodweu4.vssps.visualstudio.com"

See Network Configuration for more information.

Generated by Clippy Fixer · 247 AIC · ⌖ 18.7 AIC · ⊞ 36.7K · ◷