fix(webview): open Discover's external links in the in-app browser so they have a way back [PERA-4742]

[yasin-ce]

Description

• A host WebView that renders no controls of its own (the Discover tab) must not navigate itself to a third-party site: with no back or close affordance the user is stranded there until the app is force-killed. Off-origin top-frame navigations are now handed to the in-app browser, which brings its own chrome, leaving the host page in place to return to.

Related Issues

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

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

Rebased through the conflict with #1055 (PERA-4673, social-media handoff), which landed first and touches the same guard. Two things about that resolution a reviewer should know:

Ordering is load-bearing. The social-media handoff is checked before isExternalToHost. A social link is external to the host, so evaluating the external check first would route X / Telegram / Discord links into the in-app browser instead of the native app — silently reverting what #1055 just shipped. Both features' tests pass together: 7 social + 4 external-navigation, 29 in the spec.

Both web-return points are gated. main grew a second return true for plain web navigation after this branch was written; isExternalToHost is applied at both, so a deeplink-adjacent path cannot bypass the handoff.

isExternalToHost requires request.isTopFrame !== false, so an iframe cannot spawn a browser sheet.

Touches PWWebView.tsx, which PERA-4668 also touches — whichever lands second needs a rebase.

[filipetamota]

@yasin-ce QA and code review done ✅