Challenge 3: Diagnose Lost Data — Possible Solution
====================================================================

WHAT HAPPENED: the uploaded files were written directly into the
container's OWN WRITABLE LAYER — the filesystem space that exists only
for as long as that specific container instance does — rather than
into a named volume or a bind-mounted host path. A container's
writable layer is exactly as disposable as the container itself; it
was never designed to hold data that needs to outlive the container.

When the container was removed as part of redeploying (a completely
normal, expected step in any deployment process — pulling a new image
and starting a fresh container from it), Docker discarded that
container's entire writable layer along with it — including every file
that had been written to /app/uploads, since nothing about that path
was ever connected to persistent storage. The NEW container that
replaced it started with a fresh, empty writable layer, as if the
uploaded files had never existed.

This is precisely this chapter's central gotcha: data written directly
into a container's own filesystem, with no volume or bind mount
backing that specific path, does not survive container removal — no
matter how "permanent" it might have felt while the original container
was still running. The fix going forward is to mount a named volume at
/app/uploads (docker run -v uploads-data:/app/uploads ...), so that
path's contents live in Docker-managed persistent storage independent
of any single container's lifecycle.