fix: enhance modal session handling to reject on user cancellation

[MohamedArbani]

Description:
This PR enhances the openModal function to handle scenarios where the user dismisses the WalletConnect modal without completing the wallet connection process.

Key changes include:

• New Feature: Added an opt-in parameter showErrorOnReject:
  • Purpose: Determines whether an error should be shown when the user rejects the pairing.
  • Default Value: false.
• Added a subscription to the modal state using subscribeModal.
• Rejected the approval promise if the modal is closed, throwing an error with a descriptive message (User rejected pairing).
• Ensured proper handling of both approval and modal closure scenarios in a promise-based structure.

This improvement ensures the app properly handles cases where users dismiss the modal, improving UX and error feedback.

Notes for reviewer:
The following logs and behaviors can be observed with this change:

1. If the user closes the modal (via the "X" button or by clicking outside), the app immediately throws an error: User rejected pairing.
2. The approval process is cleanly resolved or rejected based on user actions.
3. Ensures closeModal() is called in all cases.

No breaking changes introduced to existing workflows.

Checklist

• Tested (Tested the modal closure rejection manually and validated proper error handling).

[kantorcodes]

@MohamedArbani

Thanks for getting this PR going :)

I like this idea, but I think the kind of error handling you're proposing should probably be an opt-in parameter with a callback that can be passed in. Otherwise, I fear that it is possible to introduce a breaking change to existing implementations

[tmctl]

hey @MohamedArbani , thanks for the contribution! Just letting you know we're reviewing the updates :)

[tmctl]

@MohamedArbani Thanks so much for your contribution

These have been tested to be working and are useful for UX. They make it possible to handle the case of closing a modal window without pairing. This prevents the openModal promise from hanging, which is otherwise rejected only after a pairing timeout.

Can you review the suggestions / questions and let me know what you think?

[tmctl]

looks good to me, thanks for the contribution!

[tmctl]

@MohamedArbani the last thing stopping this from being merged and published is signing the commits - https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification

without the test passing merging is blocked