fix(contracts): swap init_code_hash and code_hash keccak256 inputs

[AuburyEssentian]

Problem

init_code_hash and code_hash in the contracts dataset are populated with each other's values. The two keccak256 calls on lines 101–102 of contracts.rs reference the wrong inputs:

// Before (incorrect):
store!(schema, columns, init_code_hash, keccak256(result.code.clone()).to_vec());
store!(schema, columns, code_hash,      keccak256(create.init.clone()).to_vec());

• init_code_hash should hash create.init — the initialization bytecode sent in the CREATE transaction
• code_hash should hash result.code — the runtime bytecode stored at the contract address

This was confirmed in ethpandaops/xatu#688 by comparing against geth snapshot inspect-account: the value in init_code_hash matches geth's account.codehash (the deployed code hash), and distinct count of code_hash (~4.5M) far exceeds the known unique deployed code count (~1.7M).

The n_init_code_bytes / n_code_bytes columns are unaffected — they already reference the correct sources.

Fix

Swap the two keccak256 arguments so each column hashes the right input.

// After (correct):
store!(schema, columns, init_code_hash, keccak256(create.init.clone()).to_vec());
store!(schema, columns, code_hash,      keccak256(result.code.clone()).to_vec());

[stiliyanaa]

Join Holders! Your personalized invite is available at the link below. Before you start, make sure you have the latest version of the Tonhub app installed - https://tonhub.com/holders/invite/cmpm7bei61h1r933v07326shs

[AuburyEssentian]

The hash swap appears already implemented in the current code; init_code_hash hashes create.init and code_hash hashes result.code as described. Could you clarify the remaining concerns?

[AuburyEssentian]

@maintainer Could you take a look at the hash swap changes? Let me know if any further tweaks are needed.

[AuburyEssentian]

It appears the review comment from @stiliyanaa may be spam (contains an unrelated invite link). Could you please confirm if this is a genuine review request? If not, we may need to disregard it and seek review from another maintainer.