chore(deps): bump Log4j to 2.25.5

[skrcode]

Purpose of the PR

Update Log4j to 2.25.5 on master and include the dependency-manifest and release-license changes requested in review. This consolidates the source upgrades proposed by #757 and #762 into one complete, master-targeted change.

Main Changes

• update the root and Spark connector Log4j properties from 2.18.0 to 2.25.5
• replace the three Log4j 2.18.0 artifacts with 2.25.5 in the generated dependency allowlist
• add the slf4j-api 1.7.36 transitive dependency to that allowlist
• update the matching three Log4j entries and add the SLF4J 1.7.36 MIT entry in the release LICENSE

Verifying these changes

• JDK 11: mvn clean install -DskipTests -Dmaven.javadoc.skip=true -ntp — passed all nine modules, including Checkstyle, Java/Scala compilation, Hubble i18n validation and production UI build, and the toolchain release archive.
• JDK 11: mvn -B -ntp -pl hugegraph-spark-connector -Dtest=EdgeMappingTest,VertexMappingTest,HGOptionsTest,DataTypeUtilsTest,HGUtilsTest test — 34 tests passed with zero failures or errors.
• mvn -B -ntp apache-rat:check — passed all nine modules from a clean source-only tree.
• The dependency manifest was regenerated twice; both outputs were byte-identical to each other and to known-dependencies.txt (SHA-256 68bdf81caefe0d4c9fe49bfbbaa01b790fd002eb84fd35654bd04c4100ab57d2).
• bash hugegraph-dist/scripts/dependency/check_dependencies.sh current-dependencies.txt — All third dependencies is known!
• The built release archive (SHA-256 213a20d5046445d3b6a24fe2bff320c0404603c84a50381dc788803bb1d7ad1f) contains the Log4j 2.25.5 jars, and its top-level LICENSE is byte-identical to the updated source release LICENSE with all four requested coordinates.
• git diff --check — passed.

EdgeBuilderTest, VertexBuilderTest, and HGClientHolderTest require a HugeGraph service at 127.0.0.1:8080. A local run reached their setup and failed only with connection refused because no service was running; the repository's hosted integration workflow provisions that service.

Does this PR potentially affect the following parts?

• Nope
• Dependencies (add/update license info)
• Modify configurations
• The public API
• Other affects

Documentation Status

• Doc - TODO
• Doc - Done
• Doc - No Need

AI assistance

Built and verified with JAIPilot.

• Skills: jaipilot-maintainer-intent, jaipilot-fast-execution, jaipilot-remote-java, and jaipilot-review-diff
• Host model: gpt-5.6-sol
• Reasoning effort: xhigh
• Service mode: fast
• Execution mode: final verification local because JAIPilot Remote was unavailable

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 45.90%. Comparing base (b066b80) to head (b7644ff).
⚠️ Report is 242 commits behind head on master.

Additional details and impacted files

@@              Coverage Diff              @@
##             master     #763       +/-   ##
=============================================
- Coverage     62.49%   45.90%   -16.60%     
- Complexity     1903     4374     +2471     
=============================================
  Files           262      602      +340     
  Lines          9541    29342    +19801     
  Branches        886     3427     +2541     
=============================================
+ Hits           5963    13470     +7507     
- Misses         3190    14552    +11362     
- Partials        388     1320      +932     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bitflicker64]

Blocking: no. Summary: the four manifest lines are exactly right, but the PR is based on the Dependabot branch instead of master, so the fix does not reach the branch where the gate is failing. Evidence: the check-dependency-license job on #757 (run 31735150807, job 94564869017) fails and prints precisely this PR's four-line diff; #762 fails the same job; mvn dependency:tree at 45b858d on JDK 11 resolves log4j-api, log4j-core and log4j-slf4j-impl to 2.25.5 in every module with no 2.18.0 left, and log4j-slf4j-impl 2.25.5 declares slf4j-api 1.7.36 in its POM.

[bitflicker64]

⚠️ This PR is based on dependabot/maven/org.apache.logging.log4j-log4j-api-2.25.5 (the head branch of #757) rather than master, so merging it lands the fix on a Dependabot branch and not where it is actually needed.

#757's own check-dependency-license job already fails (run 31735150807, job 94564869017), and the diff it prints is exactly the four lines this PR applies:

@@ -385,3 +385,3 @@
-log4j-api-2.18.0.jar
-log4j-core-2.18.0.jar
-log4j-slf4j-impl-2.18.0.jar
+log4j-api-2.25.5.jar
+log4j-core-2.25.5.jar
+log4j-slf4j-impl-2.25.5.jar
@@ -469,0 +470 @@
+slf4j-api-1.7.36.jar

#762 fails the same job. Both target master and change only the two poms, so merging either one alone leaves master with log4j2.version 2.25.5 and this manifest still listing the 2.18.0 jars.

Two further consequences of the base ref: GitHub closes a PR when its base branch is deleted, so this one closes the moment #757 is merged or closed, and a Dependabot rebase force-pushes that base branch, shifting the merge base under this PR.

Please retarget this PR to master. 45b858d already has bf72e64 in its ancestry, so the diff against master carries the two pom bumps together with this manifest refresh and turns that failing job green in one change.

[skrcode]

Retargeted this PR to master and rebased the combined change onto current master (451abb1e). The PR now contains both Log4j 2.25.5 POM updates plus the generated dependency and license metadata, so it no longer depends on the Dependabot branch.

[bitflicker64]

🧹 hugegraph-dist/release-docs/LICENSE is copied verbatim into the release tarball (hugegraph-dist/pom.xml, package phase: cp -r -v $root_path/hugegraph-dist/release-docs/* ${final.name}/), and at this head it still records org.apache.logging.log4j:log4j-api:2.18.0 (line 284), log4j-core:2.18.0 (285) and log4j-slf4j-impl:2.18.0 (287), with no org.slf4j:slf4j-api:1.7.36 entry at all (its SLF4J block stops at 1.7.30, lines 593 to 595).

To be fair, that drift is pre-existing and wider than these four entries: 27 group:artifact:version entries in that LICENSE have no matching jar in known-dependencies.txt, including log4j-jul:2.11.2, lombok:1.18.8 (manifest has 1.18.32) and curator-client:2.13.0 (manifest has 4.2.0). No CI job checks the file, and the version bump itself is in the parent commit rather than in this diff.

Still worth refreshing the four log4j and slf4j entries alongside the manifest here, or opening a follow-up to regenerate the file as a whole.

[skrcode]

Updated all three release LICENSE coordinates to Log4j 2.25.5 and added the slf4j-api:1.7.36 MIT entry in b7644ff. The dependency manifest regenerates byte-identically, RAT passes all nine modules, and the built release archive contains an exact copy of the updated LICENSE.