Challenge 3: Ergonomic Improvement vs. Type-System Safety — Possible Solution
====================================================================

std::lock_guard IS a real ergonomic improvement over c3-3's raw
pthread_mutex_t specifically because it automates something that used
to require manual discipline: with pthread_mutex_lock/unlock, the
programmer had to remember to call unlock on EVERY exit path,
including early returns and (in C++ code using pthreads) exception
paths -- forgetting even one path caused the exact deadlock c3-3's own
warn-box described. std::lock_guard removes that entire class of
mistake via RAII: its destructor calls unlock automatically, on any
scope exit whatsoever, with no possibility of a programmer forgetting
to write the corresponding call. This is a genuine, measurable
reduction in a real, common category of bug -- unambiguously an
ergonomic win.

What lock_guard does NOT change, however, is WHO OR WHAT is prevented
from touching the protected data without holding the lock in the first
place. Per this chapter, std::mutex and the data it protects remain
two entirely SEPARATE variables in C++ -- there is nothing in the
language's type system connecting a specific mutex to a specific piece
of data, and nothing stops a different piece of code (or a mistake
elsewhere in the same function) from reading or writing that data
directly, completely bypassing the mutex and its lock_guard, with the
compiler raising no objection whatsoever. lock_guard only automates
the RELEASE of a lock that code CHOSE to acquire -- it does nothing to
enforce that every access to the protected data goes through that lock
at all.

Rust's Mutex<T> does something structurally different: the protected
data lives INSIDE the Mutex<T> itself, as its own field, with no
separate, independently-nameable variable holding it outside the
Mutex's control. The ONLY way to obtain a reference to the inner data
is by calling .lock(), which returns a guard object -- there is no
alternate code path that could ever reach the data without going
through that lock, because no such path exists to reach for in the
first place. This is why Rust's version is a genuine type-system
safety guarantee (the compiler makes an unprotected access literally
impossible to express) rather than merely an ergonomic convenience
(lock_guard makes releasing a lock you already remembered to acquire
automatic, but does nothing about a lock you forgot to acquire, or
data reached through some other path entirely).

WHY THIS WORKS AS AN ANSWER
------------------------------
This precisely separates WHAT lock_guard actually automates (the
release step, via RAII) from WHAT it leaves completely unaddressed
(any enforcement that access must go through the lock at all), and
explains the specific structural difference in Rust's Mutex<T> (data
lives inside the type itself, with no alternate access path to
express) that makes ITS guarantee a type-system one rather than merely
an ergonomic one.