refactor: centralize lock-poison unwrap in crate::sync

[Soulhackzlol]

Summary

Centralizes the lock-poison unwrap that was repeated at ~80 call sites into a single place.

panic = "abort" (release) means a std lock can never be observed poisoned, so every .lock().unwrap() / .read()/.write() .unwrap() was provably-infallible noise, repeated everywhere and re-derived by each reader. This adds crate::sync with thin Mutex / RwLock newtypes whose lock / read / write return the guard directly.

• Call sites become plain .lock() / .read() / .write().
• The "this cannot actually fail" reasoning lives in one doc comment instead of at every site.
• Poison handling is now a property of the type, so new code is clean by construction and can't reintroduce the noise.

Behavior is identical to the old per-site unwrap: infallible in release, loud fail-fast on the unwind-only poison path in debug. It deliberately does not recover via into_inner (that pattern only helps an unwinding long-running server, which is moot when every panic aborts the process).

Also turns three dead if let Ok(_) = .lock() poison-branches into unconditional locks.

Deliberately left untouched

• The async tokio publish_lock (different primitive, uses .await).
• web::SETTINGS_WRITE_LOCK, which intentionally keeps std poison recovery so a panic mid-save can't wedge later config writes. It's the one place poison handling is a real choice, not noise, and its comment now says so.

Testing

• cargo clippy --all-targets -- -D warnings clean.
• 282 tests green, release build OK.
• Zero-cost: #[inline] newtype over the std lock, same layout and codegen.

Notes

• No new dependencies (kept off parking_lot on purpose - its speed edge is irrelevant here since these locks are uncontended and the bottleneck is the syscall, and it would grow the dependency tree the project keeps minimal).