Data-trie key collision in the AutoBalance migration path silently deletes committed state and makes transaction state roots nondeterministic — externally triggered consensus halt

The raw-key fallback in `retrieveValueFromTrie` classifies a leaf as legacy by lookup order alone, and the version-blind trie `Get` matches on key bytes (`bytes.Equal` in `leafNode`), so when a contract writes storage key K2 = blake2b(K1) the fallback for K2 lands on K1's committed AutoBalance leaf at physical position blake2b(K1), mislabels it `NotSpecified`, and `deleteOldEntryIfMigrated` deletes it — silently and permanently destroying K1's committed value. The same mislabel makes the committed state root of a transaction a function of Go map iteration order: `updateTrie` flushes `dirtyData` unsorted, so one transaction writing both K1 and K2 commits two different tries across executions, and in a full consensus group the block can never be notarized — one cheap transaction kept in the mempool halts the chain, the same failure category as the September 2026 mainnet incident. The AutoBalanceDataTries flag has been active on mainnet since epoch 1265 (network now at epoch 2255), so any deployed contract can trigger this with a plain transaction; journal-revert resurrection of written values and cross-key reads follow from the same root cause, while protected `0x00`-prefixed system keys are out of reach. Verified at three levels on unmodified master (497f0f57): unit PoC, passing chain-simulator tests, and the live local network, where committed rounds show both INTACT and DESTROYED outcomes for byte-identical transactions. Suggested fix: verify the original key embedded in `TrieLeafData` on raw-position hits before classifying a leaf as legacy, and flush `dirtyData` in sorted key order.