Add native DOGE token predeploy

[dghelm]

Summary

• Add the native DOGE ERC-20 surface backed by native balances and a restricted native-transfer precompile, with INativeDogeToken matching the concrete NativeDogeToken predeploy naming convention.
• Follow the Celo transfer-precompile convention: low-level call status determines success and successful calls return empty data.
• Wire genesis/config to install it at 0x530000000000000000000000000000000000d09e, a DogeOS vanity slot in the 0x5300 predeploy namespace while leaving the inherited low Scroll-system range open.
• Use L2_MAX_NATIVE_DOGE_SUPPLY as the primary genesis supply config, with L2_MAX_ETH_SUPPLY kept as a matching legacy alias while downstream tooling migrates.
• Add a bytecode export script for hardfork/testnet validation and focused coverage for transfer, allowance, precompile, and genesis behavior.

Bytecode export

• Run yarn export:native-doge-token to write volume/native-doge-token-predeploy.json from volume/config.toml.
• The JSON includes the predeploy address, native-transfer precompile address, runtime bytecode, runtime bytecode hash, total-supply slot, and total-supply slot value.
• Current runtime bytecode hash: 0x90a64eee730d7b76311162eaac2977d5a2f0608dc01641e365c4173aa8da1384.

Notes

• This keeps L2_WDOGE in genesis because the bridge and gateway stack still depends on it.
• The unused P2PKH verifier predeploy reservation is not included.
• The regenerated runtime bytecode and hash must replace the previous payload in the Reth Tsuki transition.

Validation

• yarn export:native-doge-token
• forge script scripts/deterministic/ExportNativeDogeTokenPredeploy.s.sol:ExportNativeDogeTokenPredeploy --sig 'run(uint256)' 12345 --evm-version cancun
• forge test --match-path src/test/dogeos/NativeDogeToken.t.sol -vvv --evm-version cancun
• forge test -vvv --evm-version cancun
• git show --check --format=short HEAD

[dghelm]

Cross-repo compatibility note from the Tsuki runtime/docs review: the token and the pinned transfer precompile currently disagree on the success ABI.

NativeDogeToken._nativeTransfer requires both call success and 32-byte returndata decoding to uint256(1):

(bool success, bytes memory ret) = DogeOSPredeploy.NATIVE_TRANSFER_PRECOMPILE.call(...);
if (!success || ret.length != 32 || abi.decode(ret, (uint256)) != 1) {
    revert ErrorNativeTransferFailed(...);
}

But dogeos-revm tag tsuki-v0.8 returns empty bytes on a successful transfer (PrecompileOutput::new(GAS_COST, Default::default())). Against the actual pinned pair, transfer and transferFrom therefore revert even when the precompile-level native balance move succeeds. The current suites miss this because the Solidity tests mock the precompile and the direct revm tests do not assert returndata shape.

I recommend aligning this PR with the Celo token-duality convention: check low-level call success and discard returndata. The pinned reference is celo-org/celo-monorepo, packages/protocol/contracts/common/GoldToken.sol at commit 86dd8bfc; both _transfer and transferFrom use (success, ) = TRANSFER.call(...); require(success, ...).

Concretely for this PR:

• Change _nativeTransfer to treat low-level call success as success without requiring returndata.
• Add a regression test where the mocked precompile succeeds with empty returndata and the token call succeeds.
• Keep failure coverage proving a reverted/failed precompile call produces ErrorNativeTransferFailed without persistent balance or allowance changes.
• Regenerate the exported runtime bytecode/hash after the Solidity change.
• Coordinate the new bytecode/hash into the dogeos-reth Tsuki transition; its current embedded predeploy bytecode contains the 32-byte/1 check.

The cross-repo exit criterion should also include one integration test that executes the regenerated predeploy bytecode through the actual revm transfer precompile, rather than mocks on either side.

[shu-unifra]

As the canonical ERC-20 surface for the native asset, this contract will be a first-class DeFi integration target, and modern integrations increasingly assume EIP-2612. Because the bytecode is installed via hardfork, adding it later means another full Tsuki-level coordination cycle. Worth an explicit decision now rather than by default.