fix(walletconnect): show a connecting state while a scanned QR is handled [PERA-4748]

[yasin-ce]

Description

Scanning a WalletConnect QR stilled the camera and showed nothing while the pairing ran, so a multi-second connect looked identical to a hang.

• Adds an isHandling flag covering the window between a code being accepted and the deeplink resolving, with a dimmed spinner over the stilled frame.
• Cleared on all three handleDeepLink outcomes plus the catch and on visibility change, so the frame is never left dimmed.

Related Issues

• closes https://algorandfoundation.atlassian.net/browse/PERA-4748

Checklist

• Have you tested your changes locally?
• Have you reviewed the code for any potential issues?
• Have you documented any necessary changes in the project's documentation?
• Have you added any necessary tests for your changes?
• Have you updated any relevant dependencies?

Additional Notes

Copy is deliberately neutral ("Just a moment...") rather than "Connecting...". The flag is set for every handled deeplink type, not only WalletConnect — the browser paths are also slow and ASSET_OPT_IN dispatches detached. Most types resolve within a frame, so the overlay is a brief flash and must not claim to be connecting to something. The ticket's wording was WalletConnect-specific; this covers the whole class instead.

Layering is load-bearing. The overlay is last in document order among the scanner's own layers so it covers the camera, but still ahead of NotifierWrapper's toast, which has to stay on top — an explicit zIndex here would hide the WalletConnect error behind it, which the existing comment in that file warns about.

Hand-rolled instead of PWLoadingOverlay. That component has the right shape, but it renders through PWOverlay → rneui Overlay, i.e. its own Modal, and nesting a Modal inside the scanner's Modal is the same layering trap. Noted in a comment so the next reader doesn't have to re-derive it.

Not covered here: the web scanner (QRScannerContent.web.tsx) has a parallel handling path with no equivalent flag, so the extension still shows a frozen frame. Worth its own ticket rather than widening this PR. Also worth one on-device look that the overlay fills the frame — the layout is flex: 1 with an absolutely-filled camera, and nothing between Modal → NotifierWrapper → BaseErrorBoundary guarantees the children fill the screen.