Challenge 3: Session Data Disappearing After Promoting a Folder to
an Application -- Solution Walkthrough

What most likely happened: while the subfolder was a plain virtual
directory, it shared its parent's .NET AppDomain entirely, which
means it also shared the parent's in-process session state -- any
session data the parent set was directly visible to code running in
that subfolder, since there was no AppDomain boundary between them.
Converting the subfolder into its own application gives it its own
isolated AppDomain, which is exactly the isolation benefit that
conversion is meant to provide -- but a direct consequence of that
isolation is that in-process session state no longer crosses the new
application boundary. Code in the newly-promoted application can no
longer see session data set by its former parent, even though the
URL structure and site layout look completely unchanged to a visitor,
because the underlying AppDomain the code runs in is now a genuinely
different one.

No other code changed because none needed to -- the break isn't a
bug introduced by editing application logic, it's a direct structural
consequence of the promotion itself silently removing something the
code had been implicitly relying on.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader connects the chapter's own
named gotcha (session state doesn't cross application boundaries)
to a concrete symptom, and understands it as an inherent side effect
of AppDomain isolation -- not a coincidental bug that happened to
appear at the same time as the conversion.