Exercise 2: Running vs. Dot-Sourcing a Script — Possible Solution
====================================================================

THE DIFFERENCE
------------------------------
Running .\script.ps1 normally executes the script in its own CHILD scope - a separate, temporary scope that exists only for the duration of that script's execution. Dot-sourcing it with . .\script.ps1 (the leading dot, then a space, then the path) instead runs the exact same script's contents directly inside the CURRENT scope - your own interactive session's scope, or the calling script's scope.

WHY A FUNCTION IS ONLY CALLABLE AFTERWARD WHEN DOT-SOURCED
------------------------------
Anything a script defines - functions, variables - is created inside whatever scope that script is actually running in. When run normally, the script's own child scope (and everything defined inside it) is discarded the moment the script finishes, so Get-Square never existed anywhere the calling session can see once .\tools.ps1 completes - calling Get-Square 4 afterward fails because, from the calling session's point of view, it was never defined at all. When dot-sourced, the script runs directly in the current scope, so Get-Square is defined in that same scope - it doesn't get discarded when the script "finishes," because there was never a separate child scope enclosing it in the first place. It remains callable for the rest of the session.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly describes the child-scope-vs-current-scope distinction between the two invocation styles, and correctly explains that a normal run discards its child scope (and everything in it) on completion while dot-sourcing never creates that separate scope to begin with, which is why the function persists only in the dot-sourced case.