fix(pairing): navigate once when the supplicant connects

[dschom]

Because

• Tapping Connect on the v2 mobile supplicant routed to the "One last step to sync" screen twice, pushing a duplicate history entry that dropped the query string.
• Failures on channel open and on approval also routed twice, once from the integration's own Failed state and again from the promise catch.

This pull request

• Drops the then navigation in the Connect handler; the WaitingForAuthority state change is the single navigation to approve_signin.
• Routes both catch paths through navigateWithQuery with replace, and only when the integration has not already moved to Failed.
• Passes { replace: true } for the approve_signin navigation and the shared error handler, so neither adds a history entry.
• Removes the unused useNavigate from the container.
• Adds container tests asserting exactly one navigation for the success path and each failure path.

Issue that this pull request solves

Closes: FXA-14566

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).
• I have manually reviewed all AI generated code.

How to review (Optional)

This one is something Claude called out while working on #21256. The gap appears to be valid though. The verification has been 'pushed' left, and tests have been updated ensure a double navigation has not occurred.

Screenshots (Optional)

Other information (Optional)

The ticket's acceptance criteria only cover the Connect handler. The channel-open catch and the Failed-state guard go a step further since they share the same double-navigation cause.

The catch still routes for rejections that bypass the integration's fail(), such as a channel torn down by a concurrent Cancel, since no state change fires in that case.

navigateWithQuery's third positional argument is includeHash, not replace. The other Pair2 pages pass {}, true where they mean replace, so their navigations are pushes too. Only this container's calls are changed here; the rest belongs in a follow-up.