refactor(settings): Route pairing hand-off to the download_firefox page

[dschom]

Because

• ContinueInFirefox duplicated the existing /pair/supplicant/download_firefox
  page — the same card and copy under a second set of Fluent ids.
• The hand-off rendered inline at /pair, so it had no URL of its own and no
  view metrics.

This pull request

• Moves the deep-link hand-off onto Pair2/Supplicant/DownloadFirefox and
  deletes components/ContinueInFirefox.
• Navigates from /pair with the channel in router state, keeping the channel
  key out of the URL.
• Rebuilds the plan in a new container, so autoAttempt is read from live
  sessionStorage rather than frozen into a history entry.
• Falls back to the plain download CTA when no channel arrives, so a direct hit
  degrades instead of erroring.
• Adds the cad_firefox.download_firefox_view Glean event.

Issue that this pull request solves

Closes: FXA-14459

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)

• Key files/areas to focus on:
  packages/fxa-settings/src/pages/Pair2/Supplicant/DownloadFirefox/{index,container}.tsx
  and the navigation added to pages/Pair/Index/index.tsx.
• Suggested review order: the page, then the container, then the /pair
  navigation, then the Glean wiring.
• Risky or complex parts: the anti-loop token now has to survive a navigation.
  It lives in sessionStorage keyed on plan.target, so the container has to
  rebuild that target byte-identically — a different origin or reordered hash
  params would re-key it and reintroduce the Play Store bounce loop.

Screenshots (Optional)

I also validated that spinner is now in the button.

Other information (Optional)

• Stripping the hash means a load with no router state has no channel to hand
  off. That is the download-CTA fallback above, not an error — worth a look if
  you disagree with the trade.
• Still to verify on a device, since jsdom cannot: the Android intent URI
  carries two # (intent://…/pair#channel_id=…&v=2#Intent;…;end) and relies
  on parseUri splitting on the last one. There is no
  SUPPLICANT_DOWNLOAD_FIREFOX entry in functional-tests, so this path has
  no E2E coverage either way.
• The new Glean event appends this ticket to the cad_firefox group's existing
  bugs and reuses its data_reviews, matching what choice_view did for
  FXA-14133 — please confirm that covers a new event.

CI note

Two jobs were red on this branch and neither was caused by the pairing work —
both were already failing on main's own nightly run (pipeline 72802). The
test-only repairs are folded into this commit so the branch can go green:

• fxa-auth-server/lib/routes/account.spec.ts expected acceptLanguage
"en-US". 21c5faa5db fix(l10n): stop requesting en-US ftl files we never deploy dropped en-US from supported-languages.json, so negotiation
  resolves it to "en". That commit made the same edit to
  email-helpers.spec.ts and missed this one.
• test/remote/passkey_wraps.in.spec.ts imported VirtualAuthenticator from
  the @fxa/accounts/passkey barrel, which no longer exports it after
  192b53e271 refactor(passkey): move virtual authenticator to a testing entry point. Now imported from @fxa/accounts/passkey/testing, as
  passkeys.in.spec.ts already does.

Both fixes are independent of the pairing change, and main is still red on
these two jobs — worth landing them there too.