fix(metrics): correct login.complete for passkey sign-ins

[vpomerleau]

Because

• Every Sync passkey sign-in emitted two login.complete events, so passkey
  adoption and overall login volume have both been over-counted by roughly
  1,700 flows a week since Phase 1 GA.
• The surviving event was labelled reason=email, so Sync passkey logins were
  attributed to email sign-in and passkey conversion could not be measured from
  the backend funnel.
• The password step that completes a keys-required passkey sign-in carried no
  flow_id and no relying party, leaving a hole in the flow between the ceremony
  and the login it completes.

This pull request

• Adds an authMethod argument to setFlowCompleteSignal in
  packages/fxa-auth-server/lib/metrics/context.js, carried on the metrics
  context and copied through gather() so the flow-complete emitter can read it.
• Reads that value in packages/fxa-auth-server/lib/metrics/events.js, falling
  back to email, making it the single source of the login.complete reason.
• Removes the unconditional login.complete from the passkey ceremony in
  packages/fxa-auth-server/lib/routes/passkeys.ts, and sets the flow-complete
  signal before emitting account.login so the keys-optional path still records
  a completion.
• Derives the method from the session token in
  packages/fxa-auth-server/lib/routes/utils/signin.js, so the password step of
  a passkey sign-in reports passkey rather than email.
• Accepts metricsContext on POST /password/create, forwarding it from
  packages/fxa-auth-client/lib/client.ts and
  packages/fxa-settings/src/pages/PostVerify/SetPassword/container.tsx.
• Stops stash() overwriting a client-supplied metricsContext.service when the
  request carries none, so login.complete keeps its relying party.
• Asserts the emission count, not just the reason, in the route specs.

Issue that this pull request solves

Closes: FXA-14302

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: lib/metrics/context.js, lib/metrics/events.js,
  lib/routes/passkeys.ts, lib/routes/utils/signin.js
• Suggested review order: context.js → events.js → passkeys.ts →
  signin.js → specs
• Risky or complex parts: the statement reorder in passkeys.ts is load-bearing —
  the signal must be set before emitMetricsEvent or the keys-optional path
  emits nothing. The stash() fallback applies to any route that stashes, not
  only passkey ones.

Screenshots (Optional)

Please attach the screenshots of the changes made in case of change in user interface.

Other information (Optional)

• Pre-merge review waived: metrics-only change, no auth logic altered — the
  password.ts edit is a payload-schema addition and signin.js only derives a
  label.
• Merging drops reason='email' volume by the duplicate count and shifts
  reason='passkey' later in time. Needs a heads-up to data/PM and a dashboard
  breakpoint date.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (1)

packages/fxa-auth-server/lib/metrics/events.js:146

• The PR description says this makes metrics/events.js the single source of truth for login.complete reason, but other routes still emit glean.login.complete directly (e.g. lib/routes/passwordless.ts:319 and lib/routes/linked-accounts.ts:598). That means login.complete can still be emitted from multiple places, and those direct emitters can diverge from (or duplicate) the flow-complete reason logic here.

        if (metricsContext.flowType === 'login') {
          glean.login.complete(request, {
            uid: data?.uid ?? '',
            reason: metricsContext.authMethod || 'email',
          });