Exercise 1: += vs. StringBuilder at Scale — Possible Solution
====================================================================

WHY += GETS SLOW AT SCALE
------------------------------
Per this chapter, .NET strings are immutable - a string, once created, can never actually be modified in place. Every $result += "line $i`n" doesn't append to the existing string; it silently builds an entirely NEW string containing a full copy of everything accumulated so far, plus the new piece, then discards the old one. Across 10,000 iterations, this isn't 10,000 small, cheap operations - each successive copy has to copy a progressively larger amount of already-built text, producing real quadratic-ish cost that gets noticeably slower as the loop goes on, not linearly slower.

WHY StringBuilder AVOIDS THIS
------------------------------
Per this chapter, StringBuilder maintains an internal, genuinely mutable buffer and appends new text directly into it, rather than creating a whole new string object on every single append. This avoids the repeated full-copy behavior += relies on entirely, making it dramatically faster for a loop of this size - the operation becomes closer to linear cost rather than quadratic-ish.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies string immutability as the root cause of += slowness (a new string plus a full copy on every iteration), and correctly explains that StringBuilder's mutable internal buffer avoids that repeated copying, producing the real performance difference this chapter describes.