feat(vm): add node-level vm.constantCallTimeoutMs for constant calls

[yanghang8612]

What does this PR do?

Adds a node-level config vm.constantCallTimeoutMs (range [80, 500] ms; default 0 = sentinel meaning "use the network's maxCpuTimeOfOneTx") that extends the TVM execution-time window for triggerconstantcontract and eth_call only. Block-processing deadline is unchanged.

Pairs with vm.constantCallMaxConcurrency (default 10). The cap engages strictly when the operator's configured timeout exceeds the network's current maxCpuTimeOfOneTx; nodes leaving the timeout at 0 see no behaviour change — no new throttling, no regression on high-throughput RPC paths.

Closes #6681.

Why are these changes required?

triggerconstantcontract / eth_call are widely used for state queries and dry-runs but cap out at the same TVM deadline as block-processing (mainnet 80 ms). Operators currently have only --debug to extend this window, which also removes the block-processing timeout — unsafe for any node serving traffic, since it can desync from the network (#6266). This PR gives operators a scoped lever for the constant-call window without that side effect.

Design highlights:

• Block-processing is structurally unaffected. The constant-call branch is gated by isConstantCall, so the new code path is unreachable from block validation — guaranteed by structure, not by convention.
• Operators can only extend, never shrink. VmTimeoutPolicy.computeVmShouldEndInUs uses max(configured, networkMs) for the budget; setting a value below the current maxCpuTimeOfOneTx is a no-op (equivalent to sentinel 0).
• Cap engagement is runtime. Wallet.callConstantContract reads the live maxCpuTimeOfOneTx from DynamicPropertiesStore and passes it to VmTimeoutPolicy.isCapEngaged. If the network committee raises maxCpuTimeOfOneTx later, the cap-engagement threshold tracks it automatically.
• Sub-frames inherit the deadline. Cross-contract simulation uses the existing Program plumbing (getVmShouldEndInUs() is propagated to internal ProgramInvoke instances), so the override applies to deep call trees — the headline use case.
• Validation is config-load only. VmConfig.postProcess() rejects values outside [80, 500]. Note: at config-load time the DB isn't open yet, so this >= 80 floor is a sanity check, not a comparison against the live network value; the runtime max(...) keeps semantics correct regardless.
• Math safety. All arithmetic uses org.tron.common.math.StrictMathWrapper (max, multiplyExact, addExact) per the repo's math-check CI policy.

This PR has been tested by:

• Unit Tests
  • VmTimeoutPolicyTest (11 cases): deadline math, max-of semantics (never shrink below network), block-processing isolation, cap-engagement gate against runtime network value.
  • VmConfigTest (6 new cases): defaults 0 / 10; valid override 200 / 4; boundary 0 / 80 / 500 accepted; < 80, > 500, and cap = 0 rejected.
  • Existing ArgsTest and WalletTest / WalletMockTest still green.

Follow up

Operators currently running with --debug purely to extend the constant-call window should switch to vm.constantCallTimeoutMs=<ms> once this lands. --debug additionally extends the block-processing timeout, which is unsafe for any node serving traffic (see #6266). Release notes will spell this out at both touchpoints.

Extra details

• The VmTimeoutPolicy helper lives in common (not actuator) so VmConfig (also in common) can reference it without a circular dependency.
• Sample entries are added to both framework/src/main/resources/config.conf (commented user-facing samples) and common/src/main/resources/reference.conf (defaults so ConfigBeanFactory honours them when config.conf is silent).
• See discussion in [Feature] Add a node-level configuration to control the TVM execution time limit for constant calls #6681 (especially the @warku123 / @yanghang8612 thread on DoS framing and the @alan-eth comment on the --debug migration path) for the design rationale.