Challenge 3: Why Integration Tests Can't Reach Private Functions — Possible Solution
====================================================================

A unit test inside a #[cfg(test)] mod tests block lives INSIDE THE
SAME CRATE, in fact inside the very same file, as the code it's
testing. use super::* specifically brings everything defined in the
PARENT module into the test module's scope — and crucially, this
includes PRIVATE items too, since super::* is just a normal path-based
import operating within the same crate, and Rust's privacy rules
already grant full access to private items from other locations
WITHIN that same crate (privacy in Rust is about hiding things from
OTHER crates, not about hiding things between different modules of the
SAME crate that have the right visibility relationship). This is
exactly why this chapter's unit-test example could call add()
directly regardless of whether add was pub or not — being in the same
crate, with the right module relationship, is what actually matters.

A test inside the tests/ directory is fundamentally different: this
chapter stated explicitly that each file in tests/ compiles as ITS OWN
SEPARATE CRATE. Being a separate crate means it can only ever access
whatever the library crate exposes as its PUBLIC API — anything not
marked pub (and reachable via a fully pub path, per Chapter 6's own
"pub all the way up" rule) is completely invisible to it, exactly the
same way any other external consumer of a published crate would have
no access to its private internals. There's no "use super::*"
equivalent available here that could reach into a different crate's
private internals — Rust's privacy boundary is drawn AT THE CRATE
LEVEL for this exact scenario, not just at the module level, which is
precisely why integration tests are structurally limited to testing
only what a real external user of the library could actually use.