Challenge 2: "Doesn't Check" vs. "Assumes It Never Happens" — Possible Solution
====================================================================

"The compiler doesn't check for UB" would imply a PASSIVE gap -- the
compiler simply fails to notice or flag a potential problem, but
otherwise generates code that behaves the way the source text naively
suggests it should, bug and all. Under this weaker framing, the i + 1
> i loop would still behave exactly as literally written: i increments
until it overflows, at which point (on typical two's-complement
hardware) it would wrap to a very negative number, i + 1 > i would
then evaluate false, and the loop would terminate -- broken in the
sense that the programmer's intended stopping point (INT_MAX) wasn't
respected, but still eventually stopping.

"The compiler is ALLOWED TO ASSUME UB never happens" is a genuinely
stronger, ACTIVE claim: the compiler doesn't just fail to notice the
overflow risk -- it is standard-sanctioned in treating "i overflows" as
a case that provably cannot occur at all, for the entire remainder of
its analysis of that code. Given that assumption, the compiler is free
to conclude, via ordinary algebraic reasoning, that i + 1 > i must be
true for EVERY value i could ever legitimately take (since the only
value where it would be false -- at overflow -- has been assumed
impossible) -- and having proven the condition "always true" under that
assumption, it's entitled to optimize the loop's condition check away
entirely, producing a genuine infinite loop rather than the
wraparound-then-stop behavior a "doesn't check" model would predict.

This distinction is exactly what makes the infinite-loop example
possible: it isn't that the compiler failed to notice a bug and left
the naive wraparound behavior in place -- it's that the compiler used
the STANDARD'S OWN PERMISSION to assume overflow away as a premise in
an optimization, arriving at a DIFFERENT, more surprising result (an
infinite loop) than either the programmer's intent or a naive
"unchecked hardware wraparound" model would have predicted.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes a passive "gap in checking" framing (which would
still produce hardware wraparound behavior) from the standard's actual,
active "may assume it away" permission (which licenses eliminating the
check entirely), and traces precisely how that stronger permission
specifically produces the infinite loop rather than the more
intuitive wraparound-and-stop outcome.