feat: signed int and or support

[vr16x]

PR-Codex overview

This PR introduces support for signed integer constraints and OR conditions in the composability framework, specifically for ComposabilityVersion.V1_1_1. It updates various parts of the codebase to accommodate these new features, ensuring compatibility with version checks.

Detailed summary

• Updated version in scripts/fund:nexus.ts to V2_2_2.
• Added greaterThanOrEqualToSigned and lessThanOrEqualToSigned constraints in src/sdk/modules/utils/conditions.ts.
• Introduced GTE_SIGNED and LTE_SIGNED types in ConditionType enum.
• Enhanced createCondition to handle signed constraints.
• Updated setupMultiVersion.ts to recognize V2_2_2 with new features.
• Added new constants for V2_2_2 and ComposabilityVersion.V1_1_1 in src/sdk/constants/index.ts.
• Implemented checks for signed constraints in buildComposable.ts.
• Added tests for signed constraints and OR conditions in src/sdk/modules/utils/conditions.test.ts and src/sdk/account/decorators/instructions/buildComposable.test.ts.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[github-actions]

size-limit report 📦

Path	Size
core (esm)	71.95 KB (+0.74% 🔺)
core (cjs)	87.02 KB (+0.59% 🔺)
bundler (tree-shaking)	7.14 KB (+2% 🔺)
paymaster (tree-shaking)	543 B (0%)

[eternaut1]

//

[fichiokaku]

Looks good overall — version guards are solid and the OR/signed encoding lines up with the contract decode side. One inline note on a docstring mix-up, and one open question about test coverage:

Open question — OR containing signed sub-constraints. validateAndProcessChildConstraint allows GTE_SIGNED/LTE_SIGNED inside orConstraint(...), and the e2e tests cover OR (with unsigned subs) and GTE_SIGNED/LTE_SIGNED standalone, but I didn't see a test for the combined shape, e.g.:

orConstraint([
  greaterThanOrEqualToSigned(-1n),
  lessThanOrEqualToSigned(parseUnits("100", 6))
])

Is that intentionally out of scope for this PR, or worth adding a unit test (and maybe one integration test) before merging? It's the most likely place for a quiet encoding mismatch with the contract, since the signed sub-constraint's referenceData gets wrapped inside the OR's abi.encode(Constraint[]).

[vr16x]

Looks good overall — version guards are solid and the OR/signed encoding lines up with the contract decode side. One inline note on a docstring mix-up, and one open question about test coverage:

Open question — OR containing signed sub-constraints. validateAndProcessChildConstraint allows GTE_SIGNED/LTE_SIGNED inside orConstraint(...), and the e2e tests cover OR (with unsigned subs) and GTE_SIGNED/LTE_SIGNED standalone, but I didn't see a test for the combined shape, e.g.:

orConstraint([
  greaterThanOrEqualToSigned(-1n),
  lessThanOrEqualToSigned(parseUnits("100", 6))
])

Is that intentionally out of scope for this PR, or worth adding a unit test (and maybe one integration test) before merging? It's the most likely place for a quiet encoding mismatch with the contract, since the signed sub-constraint's referenceData gets wrapped inside the OR's abi.encode(Constraint[]).

Added additional test coverage as requested

[vr16x]

@fichiokaku Those 8 test cases failing in both paid and unit test cases are known and not related to the current scope. So optimistically skipping that as discussed