[Anurag-S1ngh]

Rationale for this change

update_schema() updates the default name mapping, and _UpdateMapping removed a mapped name from an existing field whenever a new or renamed field claimed that name. For files without field ids those names are the only way a column is found, so the removal changed what an existing column reads.

After renaming a to b, the mapping for field 1 holds both names. Adding a new column a then stripped a from field 1 and gave it to the new field. Files added with add_files were read through the name mapping, so b started reading null and the new a received the old values. Dropping and re-adding a column had the same effect.

Existing names now stay on the field they were mapped to, and newly added fields are appended to the mapping. A name that a file was written with keeps resolving to the field id it was written for, which matches the behavior of files that carry field ids. Dropped fields keep their entry in the mapping for the same reason: their names must not start resolving to a later column with the same name.

Are these changes tested?

Yes.

• tests/catalog/test_catalog_behaviors.py::test_add_column_keeps_values_of_renamed_column_without_field_ids adds a Parquet file without field ids, renames the column, adds a column with the old name, and asserts the renamed column still reads its values while the new one reads null. It runs against the memory, sql, and sql_without_rowcount catalogs and fails on main.
• tests/table/test_name_mapping.py::test_update_mapping_keeps_name_of_existing_field covers the mapping directly, and the existing test_update_mapping now expects the old field to keep its name.

Full unit suite: 4564 passed, 5 skipped. prek run -a passes.

Are there any user-facing changes?

Yes. Adding a column no longer changes the values read from files without field ids, and a reused column name no longer re-attributes their data to the new column.

Closes #4318