fix: bump Hadoop to 3.4.3 — COPY INTO Parquet/Delta/remote work on JDK 23+ (closes #183)

[fupelaqu]

Closes #183.

What

One line: project/Versions.scala:64, Versions.hadoop 3.4.2 → 3.4.3. hadoop-client,
hadoop-aws and hadoop-azure all read that constant, so they move together.

Plus the documentation that constant made false.

Why

R1FIX.4 (#188) fixed local JSON / JSON_ARRAY by routing them off Hadoop entirely, and we
concluded the rest — local PARQUET, local DELTA_LAKE, every remote scheme — was blocked
indefinitely on upstream Hadoop. It wasn't: the upstream fix shipped five months ago and we were
one patch release behind.

HADOOP-19212 "[JDK25] UserGroupInformation use
of Subject needs to move to replacement APIs" was resolved 2025-11-07, fix versions 3.4.3 and
3.5.0. Hadoop 3.4.3 was released 2026-02-24.

Verified against the actual jars rather than the changelog:

• UserGroupInformation.getCurrentUser() now calls SubjectUtil.current(). The
  AccessController.getContext() → Subject.getSubject(...) chain that COPY INTO with PARQUET / DELTA_LAKE / remote schemes fails on JDK 23+ ('getSubject') — local JSON fixed in 0.20.3 #183 died in is gone.
• SubjectUtil.current() invokes a MethodHandle built by lookupCurrent(), which findStatics
  Subject.current() (JDK 18+) and on NoSuchMethodException falls back to
  filterReturnValue(getContext, getSubject). So it works on JDK 24/25 and still on our JDK 8/11
  floor.
• hadoop-common-3.4.3 is still major version 52 (Java 8) bytecode — -target:jvm-1.8 intact.

Evidence

Check	Result
core/testOnly *FileSourceSpec forked onto Zulu 25.0.4	26 passed, 0 failed (baseline on main: 19 passed, 7 failed)
core/testOnly *LocalPathSpec *FileSourceSpec on default JDK 11	67 passed, 0 failed
core/test on default JDK 11	716 passed, 0 failed
+ core/compile (2.12 + 2.13)	clean
es8java/testOnly *CopyIntoS3* (MinIO, Docker, JDK 17)	3 passed
headerCheck scalafmtSbtCheck scalafmtCheck test:scalafmtCheck	clean

The 7 previously-failing tests were exactly read Parquet file, read Parquet file with nested structures, get Parquet file metadata, read Delta Lake table, read Delta table with time travel, get Delta table info, read Delta table with partitions. All green on JDK 25 now.

Remote schemes on JDK 25 are not covered by any suite, so they were probed directly against the
real core/Test classpath (which carries hadoop-aws-3.4.3, it being % Provided):

java         = 25.0.4
hadoop       = 3.4.3
UGI          = OK -> smanciot
s3a get      = OK -> org.apache.hadoop.fs.s3a.S3AFileSystem
VERDICT      = PASS (remote scheme resolved, no getSubject)

On that same JVM with 3.4.2, #188's Probe183 control printed
UnsupportedOperationException: getSubject is not supported. The probe used static credentials and
fs.s3a.bucket.probe=0 so the default AWS credential chain (and its IMDS probe) was never consulted.

The MinIO run is the meaningful regression check here: 3.4.3 carries a cloud-connector
reorganisation that could have moved S3A wiring. It didn't.

Docs

The COPY INTO JVM-compatibility matrix in documentation/sql/dml_statements.md collapses to all-✔.
The older-release guidance is kept, under a new "If you are on an older release" subsection —
including the DBeaver -vm recipe and the -Djava.security.manager=allow note for JDK 23 — because
users on ≤ 0.20.3 still need it. The heading text is unchanged so the existing anchor keeps working.

known_limitations.md's "Runtime / JVM limitations" section existed solely for this bullet and is
removed — a resolved item on a known-limitations page misleads anyone skimming for current
constraints. No inbound links to that anchor (checked).

Notes for review

• The version line is untouched. build.sbt:23 still reads 0.20.3-SNAPSHOT; per the epic
  release protocol the first PR to merge owns it and R1FIX.3 already claimed it. But 0.20.3 has
  just been released, so the line may well need to move to 0.20.4-SNAPSHOT — that is your call,
  not something this PR should decide. The docs deliberately do not name the version that carries
  this fix; they say "up to and including 0.20.3" for the broken releases, which is true either way.
• Not verified: abfs*:// / gs:// on JDK 25. Same UserGroupInformation root cause, now
  fixed, and hadoop-azure moves with the same constant — but there is no test for either, and the
  GCS connector is pinned separately (Versions.scala:66, hadoop3-2.2.24) and was not touched.
• This obsoletes an epic finding. The R1FIX.4 findings log records "expect exactly 7
  Parquet/Delta failures on any JDK ≥ 23 run of FileSourceSpec, do not call it a regression". With
  3.4.3 the expected count is zero, and FileSourceSpec stops being self-controlling on JDK 25.
• Companion PR: the web docs mirror is
  SOFTNETWORK-APP/softclient4es-web#31
  (feedback_dual_docs_sync). Merge the two together, web after this one.

🤖 Generated with Claude Code