Because:
* In handleNavigation's verified-OAuth path, sendFxaLogin (the
fxaccounts:login webchannel event) was dispatched synchronously
BEFORE awaiting getOAuthNavigationTarget (the /v1/oauth/authorization
HTTP call). The browser's async handler for that webchannel message
can mutate session state, racing with the in-flight HTTP request.
* This produced intermittent 401 "Token not found" failures on the
HTTP call — most reproducibly when the same browser context goes
through two consecutive OAuth flows (e.g. the vpn integration test
signing into Sync then VPN). The first /oauth/authorization
succeeded; the second one would 401 even though the session
remained valid for /account/profile, /session/status, and
/oauth/token in between.
This commit:
* Reorders handleNavigation so getOAuthNavigationTarget runs first,
obtaining the OAuth code while the session is still untouched, and
THEN fires fxaLogin and fxaOAuthLogin. The Login → OAuthLogin order
is preserved (still required for Desktop OAuth per FXA-10388).
* Adds a v1-account regression test alongside the existing vpn
integration test, using target.createAuthClient(1) so the v1→v2
upgrade path is exercised on the first sign-in even after
testAccountTracker defaults to v2 (separate PR).
closes FXA-13687