feat(encryption): support ERC-7730 encryption scheme

[melanciani]

Ported the sourcify PR's behavior (sourcifyeth/clear-signing#56) to Rust :

• provider.rs — new DataProvider::resolve_decrypted_value(chain_id, encrypted_value_hex, scheme, contract_address) with a default returning None, mirroring resolveDecryptedValue.
  Default impl means no existing implementor (or the FFI wrapper) breaks.
• engine.rs — the substance: decrypt_field_value calls the wallet, re-interprets the returned hex bytes via the descriptor's plaintextType (parse_plaintext_type → category + byte
  width), and format_value renders the plaintext with the field's normal format. On failure it renders fallbackLabel/[Encrypted]. Includes the Issue-1 width bounds check (> upper bound,
  honoring leading-zero stripping). Plus the field-level-encryption parsing plumbing.
• outcome.rs — decryption_failed and encryption_invalid_descriptor diagnostic codes.
• types/display.rs, standard_token.rs, eip712.rs — field-level encryption on Simple/Reference and pass-through.

Verification

• New tests (tests/zama_encryption_integration.rs, 7 cases): decrypt→"1 cUSDC"; no-provider→[Encrypted Amount]; wallet-returns-None→fallback; invalid hex→decryption_failed;
  over-width→decryption_failed; no-fallbackLabel→[Encrypted]; bad plaintextType→encryption_invalid_descriptor. 7/7 pass.
• Full existing suite: no regressions.
• --features uniffi,github-registry: compiles clean (FFI unaffected).
• Zama registry testsv2 via cs-test (no decryptor, exactly as CI runs): 16/16 pass — encrypted fields hit the fallback and match the fixtures.

Two deliberate divergences from the TS PR (Rust model differences)

1. Malformed annotation degrades, not fatal. The TS engine aborts the whole format; Rust's per-field renderer can only return a string, so I emit an encryption_invalid_descriptor
   diagnostic + render the fallback rather than blanking the transaction. (Arguably the better behavior — and I flagged the TS abort as debatable anyway.)
2. No rawEncryptedValue output. Rust's DisplayItem is just {label, value} (a uniffi::Record with 21 construction sites); adding a field is invasive and touches the Swift/Kotlin
   bindings. The core decrypt/fallback behavior is complete without it — worth a follow-up if you want the RECOMMENDED raw-value display.

result: Ported the wallet-delegated resolve_decrypted_value encryption model to the Rust fork on branch feat/erc7730-encryption (uncommitted, 6 files +281/−14 plus a new 7-case
integration test). Verified: 7/7 new tests pass, full suite no regressions, uniffi feature compiles, and the Zama registry testsv2 fixtures pass 16/16 via cs-test with no decryptor
(fallback path). Two documented divergences: malformed annotations degrade instead of aborting, and rawEncryptedValue output is omitted (invasive on the FFI DisplayItem).

🤖 Generated with Claude Code

[melanciani]

hey @llbartekll , did you get the time to have a look at this ?

[melanciani]

hey again @llbartekll , without this feature, new integration like ethereum/clear-signing-erc7730-registry#2595 have failing tests. Would it be possible to have a look at this PR ? thanks !