Guard success-path setState with mounted check in review send

[n13]

Summary

Follow-up to #524. Now that the send flow blocks on the RPC submission before navigating, the await in _confirmSend can take a real network round-trip (plus retries). This widens the window for the screen to unmount mid-submission.

The success-path setState was not guarded by mounted. If the widget unmounted during submission, that setState threw, the exception was caught by the failure handler, and a successful send was reported as failed (sendReviewSubmitFailed) while navigation to the success screen was skipped.

This adds an early if (!mounted) return; before the success setState and removes the now-redundant if (mounted) wrapper around Navigator.push (no awaits between the guard and the push). The failure handler already guards its setState with mounted.

Test plan

• Send a transfer normally → success screen still shows.
• Trigger a submission failure → error message shows, no navigation.
• Navigate away (back) while the confirm button is loading → no setState after dispose, no false failure logged.

[dewabisma]

Actually, this is redundant checking the mounted. As you can see on line 62, we already checked it.

And after seeing it, it's kinda weird we set state on not mounted.

[n13]

@dewabisma The line 62 mounted check doesn't cover the success-path setState, because mounted is only valid until the next await.

Between line 62 and the success setState there are real async gaps:

• await settings.getActiveRegularAccount()
• await submissionService.balanceTransfer(...) — the network RPC, plus retries

The widget can unmount during that balanceTransfer await (user hits back), so by the time we reach the success setState the line 62 result is stale. This is the standard use_build_context_synchronously rule: re-check mounted after every async gap before setState/context.

On the second point — if (!mounted) return; does the opposite of setting state while unmounted: it skips the setState when unmounted. Without it the unguarded setState throws after dispose, the catch swallows it, and a successful send gets reported as sendReviewSubmitFailed with no navigation. That false-failure-on-success is exactly the bug this PR fixes (the failure-path setState is already mounted-guarded for the same reason).

The removed if (mounted) around Navigator.push is fine to drop: there's no await between the guard and the push, so the single check covers both.

[n13]

This is a small thing we can just fix it and move on

[n13]

AI explanation above ;)

[dewabisma]

LGTM!