feat(vm): implement TIP-854 canonicalize sign-precompile calldata

[yanghang8612]

What does this PR do?

Implements TIP-854 (Canonicalize calldata for signature-verification precompiles) for java-tron, gated behind the existing ALLOW_TVM_OSAKA hardfork.

• Adds a calldata-length guard at the top of ValidateMultiSign.execute and BatchValidateSign.doExecute. The guard rejects when, with W = 32, any of the following holds: data == null, data.length % W != 0, data.length <= H*W, or (data.length - H*W) % (I*W) != 0. (H, I) are the same constants the per-call energy formula (words - H) / I already bakes in: (5, 5) for validateMultiSign, (5, 6) for batchValidateSign. Header-only calldata, i.e. empty signature arrays, is intentionally rejected.
• On reject: execute returns (false, empty) without invoking the decoder and without performing any ecrecover. The invoking call frame — reachable through any of CALL / CALLTOKEN / STATICCALL / DELEGATECALL / CALLCODE — consumes its pre-allocated energy, the stack receives 0, memory receives no return data, and the outer transaction continues with its remaining budget intact.
• For calldata satisfying the positive-tail total-length predicate (length == H*W + I*W*N for some N >= 1), the new rule is a no-op: execution proceeds into the existing decoder exactly as before. Pre-activation behaviour, including the per-call energy cost, is byte-for-byte unchanged.
• No new proposal / committee.* key / CommonParameter / Args plumbing — reuses the already-wired Osaka gate.

Why are these changes required?

The two precompiles charge energy under a fixed positive-tail total-length assumption — the pricing formula treats calldata as a static head followed by exactly N equally-sized tail slots — but the existing execute path does not enforce that same total-length predicate before decoding. The decoder follows whatever offsets calldata supplies and silently zero-pads any missing bytes through Arrays.copyOfRange. As a result, the set of byte lengths accepted by execution is a strict superset of the lengths pricing has been evaluated for: non-word-aligned trailing bytes are dropped, inputs shorter than or equal to the static head are zero-padded out or treated as empty arrays, and tails that don't decompose into an integer number of items still flow through. This makes the precompiles harder to reason about for wallets, SDKs, indexers, audits, and formal specifications. This PR closes that total-length gap by rejecting calldata whose byte length is outside the positive-tail predicate.

This PR has been tested by:

• Unit Tests
  • ValidateMultiSignContractTest: rejects malformed calldata across four buckets (non-32-aligned tail, fewer than H words, header-only empty-array calldata, aligned-but-bad-tail) plus null; positive-tail total-length input behaviour identical pre- vs post-activation; pre-activation does not take the new reject path.
  • BatchValidateSignContractTest: same four shapes, parameterised for (H, I) = (5, 6); the positive-tail case uses real 65-byte signatures so each bytes element encodes in exactly four words.
  • OperationsTest.testTip854OuterFrameContainment: drives both precompiles through Program.callToPrecompiledAddress with malformed calldata under Op.CALL and asserts (a) no exception propagates to the outer frame, (b) the inner CALL pushes 0, (c) no return data is exposed or copied to output memory, (d) the pre-allocated call energy is consumed, and (e) the outer frame keeps executing afterwards.
• Manual Testing
  • ./gradlew :actuator:compileJava :framework:compileTestJava — OK.
  • ./gradlew :framework:test --tests "*ValidateMultiSignContractTest" --tests "*BatchValidateSignContractTest" --tests "*OperationsTest.testTip854*" — all pass.

Follow up

• Validation of inner dynamic offsets, array lengths, per-element offsets, and any further decoder hardening (abi.encode conformance) is intentionally out of scope per the TIP and can be addressed in a follow-up if desired.

[CodeNinjaEvan]

LGTM