Challenge 3: Why Kotlin Errors and C# Only Warns — Possible Solution
====================================================================

// kotlin1-3's own null safety has been baked directly into Kotlin's
// type system since Kotlin 1.0 -- String and String? have ALWAYS
// been genuinely distinct types, with no way to write Kotlin code
// where this distinction doesn't apply. Because null safety was part
// of the language's foundational design from day one, the Kotlin
// compiler can treat a violation (dereferencing a String? without a
// null check) as a hard type error, on the same footing as any other
// type mismatch -- there was never a large body of pre-existing
// Kotlin code written before this rule existed that a hard error
// would suddenly break.
//
// C#'s nullable reference types arrived in C# 8, twenty years after
// C# 1.0, retrofitted onto a language where every reference type had
// ALWAYS been nullable by default the entire time. Millions of lines
// of existing C# code, written across two decades, assume the old
// nullable-everywhere behavior. If the C# compiler treated nullable-
// reference violations as hard ERRORS by default, upgrading to a
// newer C# compiler version would instantly break an enormous amount
// of previously-working, previously-compiling code the moment
// nullable reference types were enabled anywhere in a project.
// Making violations warnings instead of errors was a deliberate
// backward-compatibility choice, letting existing code keep compiling
// while still surfacing genuine risks for review -- the exact
// opposite trade-off Kotlin never had to make, since it had no
// pre-existing nullable-everywhere codebase to protect.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the real reason for the severity difference
-- Kotlin's null safety was foundational from its first release, while
C#'s was retrofitted onto twenty years of nullable-by-default code,
making warnings (not errors) a deliberate backward-compatibility
choice rather than a weaker design.