Exercise 1: A Lone Closing Bracket — Possible Solution
====================================================================

THE TEST
------------------------------
    test_input = "]"
    expected = False

RESULTS
------------------------------
    is_balanced_v2(']') = False, expected False: PASS
    is_balanced_v3(']') = False, expected False: PASS

Both versions pass this test - v2 does NOT fail here, contrary to what
a first guess might assume from the chapter's own "(]" finding.

WHY v2 HANDLES THIS CASE FINE
------------------------------
v2 tracks a running depth: +1 for any opening bracket, -1 for any
closing bracket, checking depth == 0 at the end. For "]", depth goes
straight to -1 and stays there - since -1 != 0, v2 correctly reports
False. v2's actual gap, verified in the chapter, is narrower than "any
unbalanced input": it specifically cannot detect a bracket-TYPE
mismatch when the open/close COUNT still nets to zero, like "(]"
(one open, one close, depth returns to 0, but the types don't match).
A lone unmatched closer changes the count itself, which the depth
check does catch.

WHY THIS WORKS AS AN ANSWER
------------------------------
This sharpens the chapter's own finding rather than just repeating it:
v2's blind spot isn't "type checking in general" - it's specifically
type mismatches that happen to leave the running depth net-zero. This
is exactly the kind of precise characterization a good bug report (or
a good test) should aim for - not "the function is broken" but "the
function is broken specifically when X, and correct otherwise" - which
is also why the chapter's own Cycle 3 test ("(]") was worth writing in
the first place: it was chosen specifically to isolate v2's real gap,
not just any unbalanced input.