Exercise 1: A Mixed Three-Column Schema, Real Round-Trip — Possible Solution
====================================================================

THE TEST
------------------------------
    schema3 = Schema([('id', 'INTEGER'), ('username', 'TEXT'), ('score', 'INTEGER')])
    row3 = [42, "naïve_user", -17]

    encoded3 = encode_row(schema3, row3)
    decoded3 = decode_row(schema3, encoded3)

RESULT
------------------------------
    decoded3 == [42, "naïve_user", -17]   -- exact match

WHY THIS WORKS, INCLUDING THE NEGATIVE VALUE AND NON-ASCII TEXT
------------------------------
encode_row walks the schema's own three columns in order, using each
one's own declared type to decide how to encode the matching value:

  - 'id' (INTEGER, value 42): struct.pack('>q', 42) -- 8 bytes, signed,
    positive values encode with no special handling needed.
  - 'username' (TEXT, value "naïve_user"): encode_text() computes the
    REAL UTF-8 byte length (the 'ï' contributes 2 bytes, not 1) and
    writes that as the length prefix, then appends the real UTF-8
    bytes -- exactly the fix this chapter's own bug section verified.
  - 'score' (INTEGER, value -17): struct.pack('>q', -17) -- the '>q'
    format is SIGNED 64-bit, so a negative value is stored using two's
    complement representation, the same way any real signed integer
    format works, and unpacks back to exactly -17.

decode_row walks the same three columns in the same order, using each
column's own type to know how many bytes to consume and how to
interpret them -- 8 bytes as a signed integer, or a length-prefixed
UTF-8 string. Because both encode_row and decode_row iterate the
IDENTICAL schema in the IDENTICAL order, the decoder always knows
exactly which type to expect next, and (thanks to Chapter 2's own real
byte-accurate length prefix) exactly how many bytes that field
actually occupies.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms the schema-driven encode/decode approach generalizes
past the chapter's own two-column example: three columns, a mix of
positive and negative integers, and one genuinely non-ASCII text value
all round-trip correctly together, in the same row, using the exact
same functions and the exact same fix already verified for a single
column in isolation.