Exercise 1: What Goes Wrong With Two Concurrent Applies Against Unlocked Local State — Possible Solution
====================================================================

Without locking, nothing stops both team members' `apply` commands
from proceeding through Terraform's normal cycle at the same time,
completely unaware of each other:

1. Both READ the same starting state at nearly the same moment --
   whatever state existed before either apply began.

2. Both COMPUTE a plan independently against that identical starting
   state, and both begin executing their own separate set of changes
   against the real infrastructure.

3. Both eventually WRITE an updated state file back once their apply
   finishes -- but since neither knew about the other's changes,
   each one's updated state only reflects ITS OWN changes layered on
   top of the original starting state, not the other person's.

4. Whichever write happens to land LAST wins, completely overwriting
   the file -- there's no merge, no conflict detection, just one
   write silently replacing the other.

Concretely: if person A's apply created a new database and person B's
apply (started around the same time) modified an existing instance,
and B's write happens to land after A's, the final state file reflects
B's instance change but has NO RECORD of the database A just created
in the real world. Terraform now believes that database doesn't exist,
even though it's genuinely running -- a mismatch between state and
reality that the next `plan`'s refresh step would eventually surface
as unexpected drift, but only after real confusion and wasted
investigation time.

WHY THIS WORKS AS AN ANSWER
------------------------------
This walks through the actual read-compute-write race step by step
rather than a vague "state gets corrupted," and gives a concrete
example of exactly what information gets silently lost (a resource one
apply created having no record in the final state) and why.