Propagate delete file replication factor for Hadoop ORC files

[shanthoosh]

Problem Summary

PRs #219 and #229 added support for configuring the replication factor of delete files
(delete-file-replication write option, spark.sql.iceberg.delete-file-replication session
conf, write.delete-file-replication table property). The configured value is resolved
correctly by SparkWriteConf and carried all the way into Iceberg's HadoopOutputFile, but
for ORC delete files it never reaches HDFS.

Root cause: ORC.newFileWriter short-circuits Hadoop-backed output files by handing ORC the
raw Hadoop FileSystem:

if (file instanceof HadoopOutputFile) {
  options.fileSystem(((HadoopOutputFile) file).getFileSystem());
}

ORC's PhysicalFsWriter then opens the output stream itself via fs.create(path, overwrite, bufferSize, fs.getDefaultReplication(path), blockSize) — using the filesystem default replication and discarding the replication factor carried by the Iceberg HadoopOutputFile. Iceberg's HadoopOutputFile.create(), the only place the configured replication is applied, is never invoked. As a result, merge-on-read DELETE/UPDATE/MERGE on ORC tables always produces delete files with the cluster default replication regardless of configuration.

Solution

• Expose the configured replication on HadoopOutputFile via a replication() accessor (non-positive means "not configured").
• In ORC.newFileWriter (and the matching spot in OrcFileAppender), take the raw-filesystem shortcut only when no custom replication is configured. When a replication factor is set, route the file through FileIOFSUtil.OutputFileSystem — the same path already used for non-Hadoop FileIO implementations — so the output stream is created by Iceberg's HadoopOutputFile.create(), which passes the configured replication to fs.create(...).

Behavior is unchanged when no replication is configured: the raw-filesystem shortcut is still
used and files inherit the filesystem default.

Testing Done

Unit tests — orc:TestOrcReplication (new): writes through the plain ORC FileAppender and the position-delete writer against a RawLocalFileSystem subclass that records the replication factor passed to every FileSystem.create(...) call:

• configured replication (5) reaches stream creation for data appender and position-delete writer; the file written through the OutputFileSystem path reads back as valid OR
• with nothing configured, the filesystem default replication is used (shortcut preserved)

Integration tests (SQL-only) — spark 3.5:TestOrcDeleteFileReplication (new): the catalog warehouse lives on a capturing filesystem, and the whole flow is driven through

CREATE TABLE (format-version 2, merge-on-read, ORC) → INSERT → DELETE →
SELECT file_path FROM t.delete_files:

• write.delete-file-replication'='5' table property → all position delete files created with
  replication 5; data files keep the filesystem default; SELECT after DELETE return
  rows (deletes apply on read)
• SET spark.sql.iceberg.delete-file-replication=7 session conf → delete files c
  with replication 7 (note: the hyphenated key must be backquoted in Spark SQL SET)

[cbb330]

please bump in linkedin/openhouse and set up an e2e test using sparkitest within linkedin/openhouse after this merges