Fix communication channel for the hash digest between syscall and keccak

[querolita]

While debugging SyscallReadPreimage I realized that the content of the RAM lookup on the MIPS side and the Keccak side for the hash digest (aka preimage key) was not aligned. Meaning, on the MIPS side the whole 256 bits were being taken into account for the vector lookup (32 bytes) whereas in the Keccak side it was ignoring the leading MSB (because it is meant to be substituted with a file descriptor at some point), so it was just computing the lookup with 31 bytes.

Because the preimage key bytes are stored in the registers in 8 columns of 4 bytes each, it was easier to unify the lookup so the 32 bytes are considered. Then, other parts of the system are in charge of "removing" the leading byte.

Not true, they were not being stored in the witness at all until now.

NOTE: this was not spotted before because we don't have tests for ram lookups yet, only fixed table lookups.

[querolita]

Looks like the oracle will read the 0x02 byte, so I need to adapt the communication channel to look only at the 31 bytes. This means I need to decompose the upper chunk of 4 bytes into 1 byte and 3 more bytes, and ignore the most significant one.

No need to decompose, as they were not being stored in the witness regardless. Instead, I am writing the key into the witness before calling Keccak.

[querolita]

I just learnt that the preimage key chunks were not being stored at all in the witness columns (meaning REGISTER_PREIMAGE_KEY_START is not referring to scratch state columns). Thus, I am manually storing it inside request_preimage_write() before triggering Keccak, so that the communication channel matches on both sides.

[querolita]

Checked demo, this does not halt the VM and the SyscallReadPreimage constraints hold.