fix: columns tracked by name instead of Iceberg field id

[hasyimibhar]

Fixes restart_after_dropping_a_column_keeps_field_ids, re_added_column_does_not_bring_back_dropped_values and production_keeps_large_oids.

• Restart after a drop. A restart registered each table with its discovered schema, and discovery numbers field ids by column position. After a column was dropped, the columns behind it took other columns' ids and were written under the wrong Iceberg column. An existing table now keeps its Iceberg schema, and the stream's Relation messages evolve it, in order. Discovery's view of the source's current columns doesn't apply yet at startup, because the stream may still replay transactions from before a change.
• Re-added column. A column dropped and re-added under the same name kept its old field id, so the dropped values came back. A re-add now renames the old column to <name>__dropped_<field id>, with its values intact, and adds a new column. A re-add is recognized in two ways: the column returns after it was seen dropped, or it arrives out of order. Postgres appends a re-added column after every surviving column and never otherwise reorders columns. One case can't be detected: a column re-added while it was already last, with no change to the table in between, looks exactly like a column that was never dropped.
• Reader by field id. pg2iceberg's own Parquet reader matched columns by name. That reader serves compaction, TOAST resolution, FileIndex rebuilds and verify. After a rename, it would have copied dropped values into the re-added column. It now matches by field id, as Iceberg does. It also reads files written before an int→long or float→double promotion as the new type; before, it failed on them.
• oid → long. oid is unsigned 32-bit, so values above 2³¹ wrapped negative. Existing int oid columns are promoted by the next Relation message.