Exercise 2: Re-Mounting a Path Silently Replaces Its Backend — Possible Solution
====================================================================

THE TEST
------------------------------
    backend_1 = DiskBackend(num_bytes=64)
    backend_2 = DiskBackend(num_bytes=64)
    vfs.mount('/data', backend_1)
    vfs.write('/data', 0, b'ORIGINAL')
    before = vfs.read('/data', 0, 8)         # b'ORIGINAL'

    vfs.mount('/data', backend_2)            # mount a SECOND backend, SAME path
    after = vfs.read('/data', 0, 8)

RESULT
------------------------------
    before re-mounting: /data reads b'ORIGINAL'
    after mounting a DIFFERENT backend at the SAME path '/data': b'\x00...\x00'
    (backend_1's own real data, checked directly, is still b'ORIGINAL')

/data now reads back backend_2's own fresh, all-zero bytes -- but
backend_1's own real data is confirmed still intact when inspected
directly.

WHY THIS HAPPENS
------------------------------
VFS.mount() is a single unconditional dict assignment:

    def mount(self, path, backend):
        self.mounts[path] = backend

There is no check anywhere for "does this path already have a backend
mounted" -- calling mount() a second time on the same path simply
overwrites the dict entry, exactly the way assigning to an existing
dict key always does in Python. backend_1 itself isn't destroyed or
modified in any way; its own bytearray still holds b'ORIGINAL'
perfectly intact. It's simply no longer reachable through the VFS,
since nothing in self.mounts points to it anymore -- Python's own
garbage collector would eventually reclaim it entirely if no other
reference to it existed.

WHY THIS IS A REAL, HONEST GAP WORTH KNOWING ABOUT
------------------------------
In a real file system, silently replacing what a path points to --
with no warning, and with the previous backend's own data becoming
permanently unreachable through that path -- would be a genuinely
dangerous operation (imagine a real mount command silently swapping
out an already-mounted, actively-used filesystem). This chapter's own
small VFS deliberately doesn't add that protection, matching its own
stated scope as a minimal abstraction layer -- but a production-
quality VFS would very likely want mount() to either reject an
already-mounted path outright, or require an explicit unmount() call
first, exactly the kind of safeguard this exercise's own result makes
concrete rather than assumed.

WHY THIS WORKS AS AN ANSWER
------------------------------
Directly inspecting backend_1.data (not just what the VFS reports)
after the re-mount separates two genuinely different questions: "is
the ORIGINAL data still safe" (yes) from "is the ORIGINAL data still
REACHABLE" (no) -- confirming this is a routing/reachability gap, not
a data-loss bug.