Per the comment on _wrap_data_file: we likely need to go through all the uses of DEFAULT_READ_VERSION, including this one. Reading a v3 manifest list here drops first_row_id, which is what makes a round trip fail. fetch_manifest_entry has the same issue for the new data file fields.

Fixed by adding LATEST_MANIFEST_ENTRY_READ_VERSION / LATEST_MANIFEST_LIST_READ_VERSION (derived from max() of the respective schema dicts, so they stay in sync as new format versions are added) and switching fetch_manifest_entry / read_manifest_list to read with these instead of DEFAULT_READ_VERSION. Reading an older file with the latest schema is safe since the added fields are all optional, so Avro schema resolution fills them with None. DEFAULT_READ_VERSION itself is unchanged and still used for constructing/writing records, so this only touches the two read call sites. Also added the corresponding V3 properties on DataFile (first_row_id, referenced_data_file, content_offset, content_size_in_bytes) so the values are actually exposed to callers, and extended the round-trip test to assert on their actual values rather than just presence.

copy(manifest_file) doesn't seem to work in its current form: the copy and the original share the same underlying _data list, so writing to one writes to both.

Fixed — ManifestListWriterV3._wrap now always rebinds through from_args instead of copy(), so mutating the returned manifest file's first_row_id never leaks back into the caller's record.

One thing to flag separately: ManifestListWriterV2.prepare_manifest has the same shallow-copy sharing bug (copy(manifest_file) there also shares _data). I didn't touch it since it's pre-existing and out of scope for this PR, but wanted to make sure it's on your radar — happy to file a follow-up issue if useful.

Should this be DEFAULT_READ_VERSION? It assumes any record that isn't v3 is v2, but DATA_FILE_TYPE has 15 fields for v1, 16 for v2 and 20 for v3, so a v1-bound DataFile would fail the strict zip with a confusing error.

Fixed by adding _layout_version_from_field_count, which recovers the source layout from the record's field count (each version's layout currently has a distinct field count) instead of assuming V2.

I did think about how this holds up for a future V4: if V4 only adds fields (the pattern so far), field-count inference keeps working automatically — no code change needed beyond adding the V4 schema entry, same as how LATEST_MANIFEST_ENTRY_READ_VERSION / LATEST_MANIFEST_LIST_READ_VERSION (see the other thread) are derived via max() rather than hardcoded. But if V4 ever lands with the same field count as an existing version, or changes a field non-additively, field-count inference can no longer tell them apart — so I added an explicit check that raises Ambiguous layout in that case instead of silently binding to the wrong one. That failure mode felt important to guard against explicitly rather than leave implicit.

One thing I'd like your take on: this is still inference, not the record actually knowing its own version. The more principled fix would have Record/DataFile/ManifestFile carry the format version they were bound with, so rebinding wouldn't need to guess at all — that's how Java's manifest records work, since they're self-describing rather than positional. I considered that, but went with field-count inference for now since it's consistent with the existing code's approach (the pre-existing early-return already used a field-count threshold) and, after switching reads to the latest schema, most records reaching this rebind path are already V3-shaped — it's now mostly a defensive path for records constructed programmatically at an older version, not a hot path. Changing Record's core design to carry its own version felt like the right call for a dedicated follow-up, not something to fold into this PR's scope, but let me know if you'd weigh that differently.