fix(persistent-tee): use Poseidon L1->L2 message hash for Starknet settlement

[kariy]

Problem

compute_l1_to_l2_msg_hash (persistent-tee settlement) hashes L1→L2 messages with the Ethereum keccak256 StarknetMessaging.sol formula. But saya-tee settles to a Starknet piltover core, whose canonical L1→L2 message hash is Poseidon (compute_message_hash_sn_to_appc). Katana commits to that Poseidon hash in the appchain attestation's messages_commitment — it stores the L1-handler message_hash produced by its Starknet messaging collector.

Because keccak ≠ poseidon, piltover's recomputed messages_commitment never matches Katana's for any settled block that consumes an L1→L2 message (e.g. a relayed L1-handler). piltover reverts with 'tee: invalid messages', and every subsequent block then fails 'invalid block number' — settlement stalls permanently.

This path isn't covered by the persistent-tee e2e test, which only settles plain transfer blocks (no messages), so it slipped through.

Fix

Use the Poseidon formula Katana uses, hashing over the L1-handler calldata [from_address, ...payload]:

Poseidon([from_address, to_address, nonce, selector, calldata.len(), ...calldata])
  where calldata = [from_address, ...payload]

(See katana crates/messaging/src/stream/collector/starknet.rs::compute_starknet_to_appchain_message_hash, whose result becomes the L1-handler message_hash fed into the attestation.) Drops the now-unused sha3 import.

Verification

Verified end-to-end against a local Katana rollup settling to a piltover core via saya-tee --mock-prove: blocks that consume an L1→L2 message (a mint_game L1-handler) now settle cleanly, alongside L2→L1 messages — both directions of a cross-chain demo work and saya-tee reports no settlement errors.

Scope: only compute_l1_to_l2_msg_hash. For Ethereum settlement the keccak formula would still be correct, but persistent-tee settles to a Starknet piltover core, so Poseidon is the right (and only) formula here.