Exercise 3: A Type-Mismatch Contract Violation — Possible Solution
====================================================================

THE NEW PROVIDER
------------------------------
    class UserServiceV3:
        def get_user(self, user_id):
            return {'id': user_id, 'email': 'alice@example.com', 'active': "true"}  # string, not bool

RESULTS
------------------------------
    Contract test against UserServiceV3 (active is a string):
      ["field 'active' expected bool, got str"]

    Contract test against UserServiceV2 (missing field), for comparison:
      ["missing field 'active'"]

    V3's error is a genuine type mismatch, distinct from V2's
    missing-field error: True

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms validate_against_contract() distinguishes two genuinely
different ways a provider can violate a contract - a field that's
absent entirely, and a field that's present but the wrong type - and
reports each with a message specific enough to tell them apart at a
glance. This matters in practice: "active" being the string "true"
instead of the boolean True is exactly the kind of subtle bug that
would pass a naive check like `if 'active' in payload` while still
breaking any consumer code that does `if user['active']:` expecting a
real boolean (the string "true" is truthy, so this particular case
happens to work by luck - but the string "false" would be truthy too,
silently breaking any consumer relying on it evaluating as False).
Catching the type, not just the field's presence, is what makes a
contract test a genuine safety net rather than a shallow existence
check.