fix(arrow): project date columns promoted to timestamp

[ump45nose]

Which issue does this PR close?

• Closes Date-to-timestamp promoted column reads as NULL when another column is projected #3404.

What changes are included in this PR?

type_promotion_is_valid in the field-id projection path had no arm for the v3 date -> timestamp / timestamp_ns promotions. When another column was projected in the same read, the date leaf was left out of the projection mask, so the column came back as NULL (or failed with Missing required field when required). Projecting it alone happened to work only because the mask fell back to ProjectionMask::all().

This adds the two promotions to the match, so the leaf is read and RecordBatchTransformer casts it as it already does in the single-column case.

The out-of-range case from the issue (a date that overflows timestamp_ns reads as NULL instead of failing) comes from the safe cast in the Promote path and is not addressed here.

Are these changes tested?

Yes. A new test in arrow::reader::projection writes a file with two date columns and an int column and reads it through a schema that promotes them to optional timestamp and required timestamp_ns, projecting all three. It fails on main (the required column is reported missing) and passes with the change. The iceberg lib tests and clippy pass locally.

AI Disclosure

I used an AI assistant to help locate the cause and write the test, then reviewed and ran it myself. The fix follows the one suggested in the issue. One thing worth a look: the match does not check the table's format version, same as the existing int/float/decimal arms, so a pre-v3 table with this promotion would also be read rather than rejected.