bug: zone locks up when invalid encrypted deposit refunds to TIP-403 blocked sender

[decofe]

Summary

Zone becomes permanently stuck when an invalid encrypted deposit (decryption failure) is refunded to a sender who is TIP-403 blocked as a mint recipient.

Repro

1. Sender deposits an encrypted deposit with an invalid key (decryption will fail)
2. Sender's address is blocked by TIP-403 MintRecipient policy at the time the deposit hits the zone
3. Sequencer builds advanceTempo with DecryptionData.to = sender (refund path)
4. On-chain ZoneInbox.sol calls IZoneToken(token).mint(sender, amount)
5. ZoneTip20Token precompile's enforce_mint rejects the mint because sender is blocked
6. advanceTempo system tx reverts
7. Engine retries the same L1 block every 100ms forever — zone is locked

Root cause

The ZoneTip20Token precompile enforces TIP-403 on all mints, including deposit refunds from ZoneInbox. When the refund target (the original sender) is TIP-403 blocked, the mint reverts and the deposit can never be processed, blocking all subsequent deposits and zone progress.

The sequencer only checks TIP-403 for the decrypted recipient (l1.rs:1199-1206), not the sender fallback. The on-chain contract unconditionally mints to ed.sender on failure (ZoneInbox.sol:277).

Expected / Actual

• Expected: Failed encrypted deposits always refund to sender; zone continues processing
• Actual: Zone locks up permanently if sender is TIP-403 blocked

Impact

Critical — any TIP-403 blocked address can permanently lock a zone by submitting an invalid encrypted deposit.