fix(java): drop one trailing null/undefined argument on this-calls

[kroitor]

Fixes the non-varargs call of varargs method with inexact argument type for last parameter javac warning class in ccxt's generated Java cores — 8 sites inventoried in ccxt/ccxt#29617 (PacificaCore ×2, pro/HyperliquidCore, BitfinexCore, prediction/LimitlessCore, prediction/HyperliquidCore ×2, ZebpayCore); the ninth (hand-written example) was fixed directly in ccxt/ccxt#29681.

Mechanism: the generated Java surface is uniformly (required..., Object... optionals) — 364 varargs signatures in BaseExchange.java — so a transpiled this.method(..., undefined) emits a bare trailing null that javac can't disambiguate between one-null-argument and null-varargs-array.

Fix: a Java-scoped printArgsForCallExpression override (slot was free — no prior java override) drops exactly one trailing NullKeyword/undefined argument when the receiver is this. Design notes:

• Omission over casting: behaviorally identical by proof — both terminal varargs readers on the ccxt java side (Helpers.getArg: v == null || v.length <= index → def; SafeMethods.opt: dv == null || dv.length == 0 → null) treat a null array and an empty array the same, so f(x, null) ≡ f(x) at runtime today.
• Single-drop, not greedy: bounds the blast radius; the pathological case (explicit undefined into a required trailing param) fails loudly at :lib:compileJava, never silently.
• Interior nulls and non-this calls untouched; the implicit-API path is structurally unaffected (printWrappedUnknownThisProperty packs an explicit Object[] and never had the ambiguity).

Tests: 3 new cases (safe-family + parse + handleParam shapes, single-drop/interior-null preservation, non-this negative). Full java suite 100/100; cross-language suites python+cs 93/93, php+go 72/72 — zero regressions.

Follow-up on the ccxt side after the version bump: verify zero warnings in a clean :lib:compileJava, then consider -Werror on the category so the class can't regrow.