fix(jsvm,wasm): normalize eth addresses in execTransfer bindings behind dapp forks

[33cn]

Vulnerability

The chain33 account layer ExecTransfer/ExecTransferFrozen self-transfer check compared raw from == to strings, while storage keys are normalized via address.FormatAddrKey (eth hex addresses are lowercased, ForkEthAddressFormat/ForkFormatAddressKey, active at height 0). Two string forms of the same eth address — all-lowercase vs mixed-case — are string-unequal (bypassing the from == to check) but map to the same DB key, so SaveExecAccount double-writes the same account and the balance increases by amount instead of staying constant: coins are minted out of thin air.

Reachable on-chain entry points (defense-in-depth hardening was missing even though the account-layer root cause was fixed in 33cn/chain33#1377 and 33cn/chain33#1379):

• js dapp (jsvm): execTransferFunc (plugin/dapp/js/executor/account.go, exec_transfer binding) only runs address.CheckAddress on contract-supplied from/to — a mixed-case eth address passes validation — then calls acc.ExecTransfer(from, to, ...) directly.
• wasm dapp: host bindings execTransfer/execTransferFrozen (plugin/dapp/wasm/executor/resolver.go -> plugin/dapp/wasm/executor/callback.go) do no validation/normalization at all before calling acc.ExecTransfer/acc.ExecTransferFrozen.

Fix

At both dapp entry layers, before calling the account layer, normalize from/to with the existing common.FmtEthAddressWithFork (same pattern as plugin/dapp/retrieve/executor/retrievedb.go; it respects the ForkEthAddressFormat system fork and only touches eth-format addresses):

• plugin/dapp/js/executor/account.go (execTransferFunc; note: jsvm exposes no execTransferFrozen binding)
• plugin/dapp/wasm/executor/callback.go (execTransfer and execTransferFrozen)

After normalization, case variants converge to the canonical lowercase string, so the account layer's from == to self-transfer check always hits and returns ErrSendSameToRecv.

Fork gating (consensus compatibility)

Following the ForkEVMFixOverflow pattern, two dapp forks are registered at height 0 and gate the behavior change:

• ForkJSFixAddrNormalize registered in plugin/dapp/js/types/js.go (InitFork), checked via cfg.IsDappFork(height, jsvm, ...)
• ForkWasmFixAddrNormalize registered in plugin/dapp/wasm/types/wasm.go (InitFork), checked via cfg.IsDappFork(height, wasm, ...)

Chains that need the legacy behavior can override the fork height in their chain config; before the fork height the code path is byte-for-byte the old behavior.

Tests

New executor-level regression tests (no testnode needed):

• plugin/dapp/js/executor/vuln_fix_test.go: deploys a js contract whose mint calls execTransfer. Post-fork: self transfer with from=lowercase, to=mixed-case variant is rejected with ErrSendSameToRecv and balances are unchanged; a normal transfer to a different address (mixed-case to) still works and lands on the canonical account; pre-fork (SetDappFork to a future height) the legacy behavior is preserved.
• plugin/dapp/wasm/executor/vuln_fix_test.go: exercises the execTransfer/execTransferFrozen host callbacks directly with the same three assertions.

Verification:

go test -ldflags=-checklinkname=0 ./plugin/dapp/js/executor/ ./plugin/dapp/wasm/executor/
ok  github.com/33cn/plugin/plugin/dapp/js/executor   4.003s
ok  github.com/33cn/plugin/plugin/dapp/wasm/executor 0.378s

All pre-existing tests in both packages pass. New/changed lines introduce no new gofmt/goimports issues (remaining gofmt findings in the touched files pre-date this change).