Add metadata.maps support

[melanciani]

EIP-7730 defines metadata.maps but this is currently not supported in the clear-signing sourcifyeth lib. This PR suggests to add this feature. Examples of its use can be seen in ethereum/clear-signing-erc7730-registry#2595, where a contract needs to display a tokenAmount from an underlying token

Adds ERC-7730 metadata.maps support: a descriptor can resolve a constant parameter (e.g. a token address) from a lookup table keyed on transaction context.

• params.token, params.chainId and the other constant params the schema marks map-capable accept a { map, keyPath } reference.
• Fixes a crash: an object-valued token param previously reached isAddressString() and threw s.startsWith is not a function.
• Map keys are matched case-insensitively, so checksummed address keys resolve against a lowercased @.to.
• On a lookup miss the whole format is abandoned with a DESCRIPTOR_NOT_APPLICABLE warning and the raw-calldata fallback — per ERC-7730 the descriptor does not describe the transaction. It does not degrade to a raw field.
• New DescriptorMapReference / DescriptorMetadataMap types; metadata.maps is no longer Record<string, unknown>.

Note on cross-implementation consistency: the Rust implementation
(https://github.com/llbartekll/clear-signing#) already has a maps implementation, but of a
different shape — it names the lookup bag entries rather than the spec's
values, puts keyPath on the map definition (the pre-2026-04 spec form)
rather than on the reference, and exposes a non-spec params.mapReference
that substitutes a field's display value instead of feeding constant params.
It also rejects the whole descriptor on the spec form, since params.token
is typed as a plain string. This PR follows the current
spec shape, but an ERC clarification would help both work to converge.

Open question: on a lookup miss this degrades to raw with
FORMAT_PARAM_RESOLUTION_ERROR, consistent with other unresolvable params.
The spec says a wallet MUST treat the descriptor as invalid for the
transaction — should we follow it strictly ?

[kuzdogan]

This key has a space after the comma. The ERC-7730 spec does not allow a space after a comma in a format key. The parser in this library removes the space, so the tests pass. But the registry lint tool will reject this key. Please change it to "wrap(address to,uint256 amount)". The same key is in calldata-ConfidentialWrapper.json.

_{Posted with Claude Code}

[melanciani]

good catch !

[kuzdogan]

The PR description does not match the code. The description says: when a map lookup fails, the field falls back to raw with FORMAT_PARAM_RESOLUTION_ERROR. The code does something different. When a map lookup fails, the code emits DESCRIPTOR_NOT_APPLICABLE and drops the whole format. The test "abandons the whole format" checks this. I think the code is correct. The spec says the descriptor is invalid for that transaction. Please update the PR description to match the code.

_{Posted with Claude Code}

[melanciani]

indeed, updated the PR description

[kuzdogan]

Thank you. The implementation is clean. All map references are replaced in one pass in processSingleField. The format handlers do not need to know about maps. A lookup miss follows the spec rule.

I added two small comments inline.

One more request. AGENTS.md describes the descriptor concepts and the warning codes. Please add a short section about metadata.maps. It can list three things: the shape of a map reference, where the substitution happens, and the DESCRIPTOR_NOT_APPLICABLE warning.

About the Rust implementation: I agree. An ERC clarification is the way to make the two implementations agree. This PR follows the current spec text, and that is correct.

_{Posted with Claude Code}