`tx_number_in_block` width differs between runtime (`u16`) and circuit state (`u32`)

Nobody has claimed this yet.

The runtime and circuit use different widths for `tx_number_in_block`.

Runtime side:
- `LogQuery.tx_number_in_block` is `u16` in `crates/zk_evm_abstractions/src/queries.rs`
- VM increments it with wrapping semantics in `crates/zk_evm/src/vm_state/helpers.rs`

Circuit side:
- VM state stores it as `UInt32` in `crates/zkevm_circuits/src/base_structures/vm_state/mod.rs`
- increment logic uses `UInt32` arithmetic in `crates/zkevm_circuits/src/main_vm/opcodes/context.rs`

Suggested fix:
- either enforce a hard `< 2^16` bound in the circuit and witness path
- or widen the runtime representation and document the intended max value explicitly

Compare the runtime definitions and increment logic in crates/zk_evm_abstractions/src/queries.rs and crates/zk_evm/src/vm_state/helpers.rs with the circuit state and opcode logic in crates/zkevm_circuits/src/base_structures/vm_state/mod.rs and crates/zkevm_circuits/src/main_vm/opcodes/context.rs. Determine the intended maximum and representation, then update the runtime, circuit, witness path, or documentation so the width and overflow behavior are consistent.

Written by the indexing model from the issue text.