EIP-712 perpetual receipt + TLV type 33 (raw domain)

[ignromanov]

Part of #8 · Layer 2 (interop) + Layer 1 (append: new TLV type 33) · 🟡 P2 · receipt track

What

• @void-layer/interop EIP-712 receipt build/verify.
• New even/odd TLV type 33 carrying raw EIP-712 domain fields (name + version + chainId) — the existing 32-byte domain hash (TLV type 31) is insufficient for perpetual independent verification.

Why

A verifier in 10 years cannot reconstruct the EIP-712 digest from a 32-byte hash alone without an external registry. Storing raw name+version+chainId (+~96B, compresses well) makes receipts self-describing. TLV 33 is append-only (forward-compat) — never modifies type 31.

Acceptance

• minimal raw-field set confirmed before allocating type 33
• receipt struct: invoiceId (keccak256 content hash) + payer/payee/token/amount/settledAt/chainId/codecVersion
• build + verify round-trip; type 33 passes forward-compat/dict-lock tests
• type 31 unchanged

wiki: concepts/eip-712-receipt-domain-separator-design.md