fix(bqjdbc): fix BigDecimal usage in mocks

[Neenu1995]

ci / split-units (java-bigquery, 25) check in all JDBC PRs suddenly started failing.

Root Cause Analysis

1. JDK 25 Class Layout Restructuring

OpenJDK 25 restructured the internal layouts and private fields of core classes—including java.math.BigDecimal and java.math.BigInteger—to lay the groundwork for Project Valhalla's value types and flat objects.

2. Bytecode Compatibility Break

Mockito’s final-class mocking relies on the ByteBuddy agent (v1.12.19 in this module) to instrument core JDK classes at runtime. Under JDK 25, the restructured bytecode layouts collided with ByteBuddy's instrumentation patterns. This corrupted internal math helper methods (such as needIncrement() and divideAndRound()), causing subsequent standard BigDecimal operations across the JVM lifecycle to compute incorrect values and trigger the Rounding necessary exception.

3. Strict Module Encapsulation

JDK 25 strictly enforces strong encapsulation of the java.base module. Dynamic runtime bytecode manipulation of core JDK classes is increasingly unstable without explicit compatibility updates to agents.

Resolution

By replacing mock(BigDecimal.class) with a concrete new BigDecimal("123.456") instance in BigQueryCallableStatementTest.java, we completely bypass runtime bytecode manipulation, ensuring cross-version compatibility from JDK 11 through JDK 25+.

[gemini-code-assist]

Code Review

This pull request replaces mocked BigDecimal instances with concrete BigDecimal values in several test cases within BigQueryCallableStatementTest.java, specifically in methods testing parameter retrieval and setting by index and name. I have no feedback to provide.