feat: discard the code_hash and trx_hash fields passed in during contract deployment

[lily309]

Why is this needed?

The code_hash and trx_hash fields passed in during contract deployment are unused. They do not participate in deployment processing and do not affect the deployment result or execution semantics.

Since these fields have no functional meaning as deployment inputs, this change introduces a preventive protocol restriction against their future use.

Historical transaction scan

We performed a complete scan of all historical transactions across the full chain history.

No historical contract deployment transaction was found with either code_hash or trx_hash set. The number of historical transactions carrying either field is zero.

This confirms that normal contract deployments have never relied on these fields. The restriction does not invalidate any historical transaction or alter any existing user behavior.

Implementation

The field numbers already exist in the protocol message and cannot be removed directly without affecting wire compatibility. Therefore, preventive prohibition at the protocol level must be implemented as an activation-gated validation rule.

After activation, a contract deployment transaction containing a non-empty code_hash or trx_hash is rejected during validation using the existing timeout rejection semantics. Before activation, the existing behavior is preserved.

Normal contract deployment transactions do not set these fields and are completely unaffected by this change. Contract bytecode, addresses, resource settings, constructor parameters, and all other normal deployment inputs continue to be processed exactly as before.

What does this PR do?

• Detects non-empty code_hash and trx_hash values during contract deployment validation.
• Rejects transactions carrying either field after activation.
• Preserves pre-activation compatibility.
• Leaves normal contract deployment behavior unchanged.
• Adds coverage for each field, empty values, and pre-activation behavior.

Compatibility

This change currently uses the same provisional fork version introduced by #6920.

The current branches merge without textual conflicts. If the version identifier or activation parameters in #6920 change, this PR should be updated accordingly.

Tests

• Verified code_hash rejection after activation.
• Verified trx_hash rejection after activation.
• Verified empty fields remain valid.
• Verified pre-activation compatibility.
• Verified normal contract deployment inputs remain unaffected.
• Verified existing activation-gated timeout checks.