Merge two VM fixes into the v4.8.2 Nile build:

[nileTestNet]

What does this PR do?

Integrates two upstream VM fixes into the v4.8.2 Nile build:

• fix(vm): isolate constant-call config, self-dispatch vote-witness cost tronprotocol/java-tron#6857 — fix(vm): isolate constant-call config & self-dispatch vote-witness cost
  • Self-dispatching vote-witness energy cost. getVoteWitnessCost3 now falls back to cost2 when Osaka is off, and cost2 falls back to the legacy cost when energy adjustment is off. The charged energy stays correct even if a stale cost function lingers in the shared jump table after a reorg, or is read by a constant call whose chain view has the proposal disabled.
  • Thread-local constant-call config view. Constant calls bound to a lagging solidity/PBFT snapshot used to load their feature flags into the process-global VMConfig, racing block processing during a proposal's activation-to-solidification window. The constant-call path now reads its config from a thread-local snapshot; the block/broadcast path continues to own the global config.
• perf(vm): hoist allowDynamicEnergy out of the opcode loop tronprotocol/java-tron#6858 — perf(vm): hoist allowDynamicEnergy out of the opcode loop. The dynamic-energy flag is read once per execution instead of on every opcode, removing per-instruction overhead from the hot path.

Why are these changes required?

• A stale entry in the shared cost jump table (after a reorg) or a constant call viewing the proposal as off could charge the wrong vote-witness energy. Self-dispatch makes the cost self-consistent with the currently active proposal flags regardless of jump-table state, removing a divergence risk.
• Letting constant calls write feature flags into the process-global VMConfig is a data race against concurrent block processing during the proposal activation→solidification window, and could cause a fork. Isolating the constant-call view into a thread-local snapshot closes that race.
• allowDynamicEnergy was being evaluated inside the per-opcode loop; hoisting it is a pure performance improvement with no behavioral change.

This PR has been tested by:

• Unit Tests — VMConfigIsolationTest (new) verifies a constant call cannot pollute the global VM config; VoteWitnessCost3Test (extended) covers the cost3 → cost2 → legacy fallback across proposal-flag combinations.