fix(keychain): reject dirty recipient word in is_call_allowed

[devorun]

Summary

KeyRestrictions.is_call_allowed documents that its resolution order "matches the Rust implementation", but for a recipient-constrained selector it extracts the recipient from the low 20 bytes of the first ABI word and ignores the upper 12 bytes:

word = input_data[4:36]
recipient = as_address(word[12:])
return recipient in rule.recipients

The Rust it mirrors does not. Both the client-side reference tempo_alloy::call_scopes_allow and the on-chain precompile (AccountKeychain::validate_call_scope_for_transaction) require the upper 12 bytes of that word to be zero before comparing the recipient, and deny the call otherwise:

let word: [u8; 32] = input.get(4..36)?.try_into().ok()?;
if word[..12].iter().any(|byte| *byte != 0) {
    return Some(false);
}
Some(rule.recipients.contains(&Address::from_slice(&word[12..])))

So for calldata whose first word has non-zero upper bytes but whose low 20 bytes happen to match an allowed recipient, is_call_allowed returns True while the chain rejects the call. A caller that trusts the helper to pre-check an access key would build and sign a transaction that then reverts on-chain.

Fix

Add the same zero-upper-bytes guard before extracting the recipient, so the client agrees with call_scopes_allow and the precompile.

Test

Adds test_recipient_word_dirty_upper_bytes_denied for the dirty-upper-bytes case; the existing tests only exercised well-formed, zero-padded recipient words.