Challenge 3: Why Implicit Satisfaction Can Accidentally Happen — Possible Solution
====================================================================

In Go, an interface is satisfied purely STRUCTURALLY — the compiler
only checks whether a type happens to have methods with matching
names and signatures, with no requirement that the type's author ever
intended, or even knew about, that particular interface. This means a
type can accidentally satisfy an interface it was never designed for,
simply by coincidentally having the right method names and
signatures. CONCRETE EXAMPLE: if a Go interface Closer requires a
Close() error method, and a completely unrelated type happens to
define its own Close() error method for a totally different purpose
(say, closing a physical door in a simulation, not a resource), that
type would silently satisfy Closer wherever it's used — even though
its author never intended it to represent "a closeable resource" in
that sense at all. If that type were ever passed somewhere expecting
a Closer, the code would compile and run, quietly using a method that
happens to have the right shape but the wrong actual meaning.

WHY RUST'S EXPLICIT impl Trait for Type MAKES THIS SPECIFIC MISTAKE
IMPOSSIBLE: in Rust, having a method with a matching name and
signature is never enough on its own — a type only satisfies a trait
if its author (or someone with access to the type/trait, per the
orphan rule) explicitly writes `impl TraitName for TypeName`
somewhere. A type with a method that happens to be named summarize
and returns a String does NOT automatically implement the Summary
trait from this chapter — nothing satisfies Summary until an impl
block explicitly says so. This means the accidental-satisfaction
scenario described above for Go simply cannot occur in Rust: every
trait a type satisfies was a DELIBERATE choice made by whoever wrote
that impl block, not an accident of two unrelated method signatures
happening to line up.