fix(trie): make TrieImpl.insert() idempotent for duplicate key-value

[halibobo1205]

Summary

Fix two bugs in TrieImpl.insert() that together break Merkle Trie idempotency when the same key is put more than once (regardless of whether the value changes):

1. Correctness (root-hash corruption). Reorder the condition checks in insert() so thatcommonPrefix.equals(k) is evaluated before commonPrefix.isEmpty(). The two conditions overlap only when both k and currentNodeKey are empty, which the recursion reaches exclusively on a duplicate put of an already-inserted key on a fully-split KV leaf. In that state, the old order incorrectly triggered the "no common prefix" branch and replaced KVNode("", v_old) with BranchNode{terminal: v_new}, corrupting the trie structure and, in turn, the root hash. This happens whether or not the new value equals the old one.

2. Optimization (avoid unnecessary recomputation). Short-circuit kvNodeSetValueOrNode() when the new byte[] value equals the existing one (by reference or byte content) to skip redundant dirty marking and downstream hash recomputation on the KV-leaf path. This does not by itself fix the root-hash corruption; it only reduces cache churn. Branch-terminal writes and Node-valued writes are intentionally not short-circuited (parent nodes still need dirty propagation when a child is mutated in place).

Closes #6608.

When the bug triggers

• ❌ Every key put at most once per trie → not triggered, no impact.
• ✅ Same key put ≥ 2 times (same or different value) → triggered,root hash becomes insertion-order-dependent.

The only production path into TrieImpl is AccountStateCallBack. Its trieEntryList is an undeduplicated ArrayList: if multiple transactions touch an account in the same block, `trie.put(addr, …) is called multiple times with the same key, hitting bug 1.

Consensus impact and release scope

AccountStateCallBack is gated behind proposal 25 (ALLOW_ACCOUNT_STATE_ROOT), which has not been activated on mainnet or nile. Therefore, this fix has no impact on the current consensus.

If proposal 25 is ever activated, AccountStateCallBack will compute per-block account-state roots stored in block headers. Without this fix, two honest nodes processing the same block — where any account is modified by more than one transaction — could compute different state roots and fork. This fix must therefore be merged and released before any release that could run a chain on which proposal 25 may activate.

• Hard requirement: MUST be included in any release shipped before or
  during ALLOW_ACCOUNT_STATE_ROOT activation.

See #6608 for the full reproduction and affected code paths.

[waynercheung]

[MUST] The consensus-impact analysis is already documented in #6608, but per the repo’s consensus-change requirements, please mirror a short summary into the PR description itself and explicitly document:

1. the target release / upgrade scope for this fix;
2. that this fix must be included in any release intended to run before / when Proposal 25 (ALLOW_ACCOUNT_STATE_ROOT) may activate.

A short summary referencing #6608 is sufficient; no need to restate the full analysis.

Optional cleanup: since this PR already touches TrieTest.java, it would also be nice to remove the two pre-existing System.out.println lines at TrieTest.java:67-68 in this PR if convenient. If you prefer to keep this PR tightly scoped, a small follow-up cleanup PR is also fine.

[halibobo1205]

@waynercheung

1. The PR description is updated.
2. TrieTest.java:67-68 is cleaned up.

[lvs0075]

I have a question regarding the description: the current code does not affect the consensus. The modification is merely intended to ensure that the results of the random write are consistent.