Validate terms is Hex, rather than validating each erc20 token address individually

[jeffsmale90]

Explanation

Previously we used the isHexAddress function to validate the erc20 token address. This function expects the input value to be in lowercase hex.

Because we are splitting the address from the terms, now we just validate that the entire terms is valid Hex (using case-insensitive function) in the makePermissionRule function.

no-changelog because this is a fix to an unreleased change.

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Changes shared permission decoding/validation by rejecting any non-hex terms upfront and removing per-rule tokenAddress hex checks; this can affect which permissions are accepted/rejected across all rules.

Overview
Moves hex validation to makePermissionRule by rejecting any caveat whose terms are not a strict hex string (while still allowing empty 0x), preventing downstream decoders from operating on malformed data.

Removes isHexAddress checks from the ERC20 stream/periodic decoders so mixed-case token addresses in terms are accepted, and updates tests to cover mixed-case addresses while dropping rule-specific “invalid token address characters” cases.

^{Written by Cursor Bugbot for commit 8e8f420. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}