Challenge 3: Why using namespace in a Header Is Worse Than in a .cpp File — Possible Solution
====================================================================

Per c2-4's own material, #include is literal, unconditional TEXT
PASTING -- the preprocessor copies a header file's entire contents,
verbatim, into the exact spot where #include appears, before
compilation even begins. This means whatever a header file contains
becomes part of EVERY SINGLE source file that includes it, with no
exceptions and no isolation between them.

If `using namespace X;` is written directly in a SINGLE .cpp file, its
effect is confined to that one file alone -- the directive is pasted
(trivially, since it's already there) only into that file's own
compilation, and no other source file in the project is affected by
it at all. The collision risk it introduces is local and contained.

If the identical `using namespace X;` is instead written inside a
HEADER file, then per #include's own text-pasting mechanism, that
directive gets copied into EVERY file that includes that header --
directly, or transitively through another header that itself includes
it. A project might have dozens of source files including that one
header, none of which ever explicitly asked for `using namespace X;`
themselves, and yet every one of them silently gets X's entire
namespace dumped into their own global scope regardless. The collision
risk isn't confined to one file anymore -- it becomes an
uncontrollable, project-wide side effect of a single header's own
choice, imposed on every consumer of that header without their
knowledge or consent.

WHY THIS WORKS AS AN ANSWER
------------------------------
This grounds the answer specifically in #include's own text-pasting
mechanism from c2-4 (not just "headers are more powerful"), and
explains precisely why the SAME directive has a contained effect in one
file but a project-wide, uncontrollable effect when placed in a header
that many files include.