fix: use the current schema when reading matched rows in upsert

[JooyoungJeong]

Closes #2467

Rationale for this change

Transaction.upsert() pins the target branch with use_ref(branch), which sets a snapshot id, so TableScan.projection() resolves the schema recorded on that snapshot rather than the table's current schema. A schema-only update creates no data snapshot, so the branch tip can still carry the pre-update schema, and the matched rows are then read with a schema that no longer matches the input dataframe.

An added column surfaces as ValueError: Target schema's field names are not matching the table's field names in get_rows_to_update(). A renamed non-key column fails the same way, and a renamed join column fails earlier still, in has_duplicate_rows(), with KeyError.

The change is one call site in pyiceberg/table/__init__.py: the scan that reads the matched rows now projects the current table schema. File planning is untouched and still uses the pinned snapshot, so time-travel and ref scan semantics do not change. ArrowScan already binds the row filter against table_metadata.schema(), so the projection was the only part still tied to the snapshot's historical schema.

Are these changes tested?

Yes. Four cases added to tests/table/test_upsert.py, each of which fails on main:

• test_upsert_after_adding_column
• test_upsert_after_renaming_column
• test_upsert_after_renaming_join_column
• test_upsert_after_adding_column_in_transaction

uv run pytest tests/table/test_upsert.py -q → 27 passed.

Are there any user-facing changes?

No.

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that's incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[github-actions]

This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.