fix: ignore reader-side parquet.hadoop.vectored.io.enabled in Iceberg native-write detection (#5410)

Avoid mis-classifying Compatible Iceberg V2 writes as Unsupported due to
well-known parquet reader settings.

CometIcebergNativeWrite's `requireNoParquetHadoopConfOverrides` (added
in #5298) walks the entire session Hadoop Configuration and returns an
`Unsupported` fall-back reason for any key starting with `parquet.`.
The intent is sound (a `parquet.*` key in the Hadoop conf reaches
iceberg-java's writer but not Comet's native writer), but the
predicate is too broad: it checks reader-side `parquet.*` keys the
same as writer-side ones.

`parquet.hadoop.vectored.io.enabled` is a reader-side vectored-IO
knob:

- Declared in parquet-hadoop as
  `org.apache.parquet.hadoop.ParquetInputFormat.HADOOP_VECTORED_IO_ENABLED`
  with default `true` in parquet-hadoop 1.16+.
- Only consulted by parquet-mr's Hadoop reader path (via
  `HadoopReadOptions.useHadoopVectoredIo`); iceberg-java's writer
  never reads it.

Any environment that seeds it into the session Hadoop configuration
trips this rule, and every otherwise-Compatible Iceberg V2 write is
silently mis-classified as Unsupported — the native writer is
disabled without the user having changed any writer-relevant setting.

Add an `IgnoredHadoopParquetConfKeys` set containing
`parquet.hadoop.vectored.io.enabled` and consult it inside the
`parquet.*` walk before emitting the fall-back reason. The broad
`startsWith("parquet.")` gate remains in place for every
writer-relevant knob.

Add a regression test that pins
`parquet.hadoop.vectored.io.enabled=true` in the session Hadoop
configuration via `withSQLConf` and asserts Compatible. The existing
negative test ("fall-back: parquet.* key in the session Hadoop
configuration", keyed on `parquet.block.size`) continues to exercise
the rejection path for real writer-relevant `parquet.*` keys.

Co-authored-by: Steve Vaughan Jr <s_vaughan@apple.com>