Why this matters
The bug. Mutex::lock() returns a MutexGuard — a smart pointer that dereferences to the protected value *and* releases the lock when dropped. Calling .clone() on what the guard points to (via auto-deref) copies the inner Config, then the guard immediately drops. The subsequent config.key = ... mutates the local clone, which is then discarded at end of scope.
The fix. Drop the .clone(). Bind the guard itself; the deref-coerce on the next line writes through to the shared Config.
Why this slips past review. It looks like the standard 'lock → mutate' idiom. The .clone() was probably added to silence a borrow-checker complaint earlier in the file's history and never re-questioned.
Review heuristic
Library functions that take an object and mutate it should be loud about it (named sortInPlace, not sort). Sites that pass a config object through a chain of middleware should not allow any link in the chain to mutate it.