[rmannibucau]

Fixes #9037

Change description

CalculatorMetaFunction lost its legacy -1 default for valueLength / valuePrecision when PR #795 (HOP-2849) replaced the hand-written XML loader with @HopMetadataProperty-based automatic (de)serialization. A plain private int valueLength; / private int valuePrecision; now deserialize to Java's default 0 when the tag is absent, whereas the old loader defaulted to -1 — the sentinel for "unspecified length/precision" used by CalculatorMeta.getValueMeta() and by CalculatorDialog (which reads blank cells back as -1 and only shows a length >= 0).

This PR initializes both fields to -1 so a legacy restore keeps the sentinel instead of collapsing it to 0.

Tests

Regression tests added in CalculatorMetaFunctionTest:

• Restoring a legacy XML without <value_length> / <value_precision> now asserts -1 (this test fails on current main with expected: <-1> but was: <0>).
• Restoring XML with explicit value_length / value_precision asserts the values are preserved (and not clobbered by the -1 default).

Verification

• mvn -pl plugins/transforms/calculator test (module calculator): CalculatorMetaFunctionTest 4/4 green with the fix; the legacy-restore test fails without it.
• apache-rat:check on the module: 0 unapproved licences.
• spotless:check: OK.

Notes

Build verified against the repo's pinned JDK 21 (21.0.12-tem); the default JDK 26 in this environment breaks spotless / google-java-format (NoSuchMethodError in javac).

[bamaer]

Thanks @rmannibucau. Built the PR and ran the calculator tests (86/86 green); with the two field initialisers reverted, testRestoreLegacyXmlWithoutLengthPrecisionDefaultsToMinusOne fails with expected: <-1> but was: <0>, so the test covers the regression. This also gives metadata-injected calculations without a mapped length/precision the same -1 as a blank dialog cell. LGTM.