Challenge 3: Diagnose a Field Numbering Mistake — Possible Solution
====================================================================

WHAT COULD GO WRONG: any client, service, or stored/serialized data
that was built against the OLD schema (where field number 3 meant the
deprecated field) has no way of knowing the meaning of number 3 has
changed. Because the wire format identifies fields purely by NUMBER,
not name, an old client sending or receiving a message with field 3
still populated according to the OLD field's type will have that data
silently misinterpreted as the NEW field's type instead — a string
might be read where an integer was expected, or vice versa, with NO
error raised by the deserialization process itself. This can produce
corrupted-looking data, subtly wrong values, or a crash somewhere
downstream, all without any obvious "schema mismatch" error pointing
at the real cause.

This is especially dangerous because it can go unnoticed for a long
time — if only some clients have upgraded to the new schema while
others (or old stored data) still reference the deprecated field 3's
old meaning, the bug only surfaces when both versions actually
interact, which might be much later than when the number was reused.

THE CORRECT APPROACH: when field 3 was deprecated and removed, it
should have been marked with the reserved keyword:

message Example {
  reserved 3;
  // ... other fields, none reusing 3
}

This tells the Protocol Buffers compiler itself to reject any future
attempt to reuse field number 3 for something new, catching the
mistake at compile time rather than allowing it to silently ship and
cause a real, hard-to-diagnose data-corruption bug in production.