fix(functional-tests): register recoveryKey accounts with the tracker

[vbudhram]

Because

• recoveryKey.spec.ts built its account details from generateEmail(), which only returns a string. It never registered the account with TestAccountTracker, so teardown could not destroy it.
• The in-test UI delete was the only removal. Any failure before it left a real account on stage, with no error and nothing in CI. The spec runs 8 parameterized cases.
• changeEmail.spec.ts re-pointed credentials.email only at the end of each test. If a test failed after the promotion, the tracker held an address that was by then a secondary, and cleanup's sign-in failed.

This pull request

• Replaces the hand-built object in recoveryKey.spec.ts with testAccountTracker.generateAccountDetails(). It uses the default signin email prefix and registers the account.
• Keeps the in-test UI delete. destroyAllAccounts() checks accountStatusByEmail first and skips accounts that no longer exist.
• Moves each credentials.email re-point in changeEmail.spec.ts to directly after the promotion it tracks. This covers the four tests that swap the primary email. The third test promotes twice, so it re-points twice.
• Re-points the password in the fourth test directly after the new account is created.
• Drops two trailing password assignments that these moves made into duplicates.

Issue that this pull request solves

Closes: https://mozilla-hub.atlassian.net/browse/FXA-14285

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: line 82 of recoveryKey.spec.ts, and each credentials.email assignment in changeEmail.spec.ts.
• Suggested review order: recoveryKey.spec.ts first, then changeEmail.spec.ts test by test.
• Risky or complex parts: generateAccountDetails() returns the tracked object by reference. The existing accountDetails.password = newPassword line therefore keeps the tracker in sync after the reset.

Screenshots (Optional)

None. There is no user interface change.

Other information (Optional)

I did not run the specs locally. They are Playwright functional tests. They need a running stack and real stage accounts, so CI covers them. I ran these checks instead:

• tsc --noEmit on packages/functional-tests. It reports three pre-existing errors in lib/. The output is identical to the baseline with the changes stashed, so this branch adds no new errors.
• nx lint functional-tests: exit 0, 0 errors.
• prettier --check on both files: clean.

One trade-off. A failed promotion now leaves the tracker on an address that is only a secondary. This is the same class of failure as before, but it fails loudly, unlike the silent leak this PR fixes.

No assertion changed. No test was added, removed, or skipped. lib/testAccountTracker.ts is untouched.

[Copilot]

Pull request overview

Improves functional-test account cleanup after failures.

Changes:

• Registers recovery-key test accounts with TestAccountTracker.
• Updates tracked email/password credentials earlier during account mutations.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
packages/functional-tests/tests/settings/changeEmail.spec.ts	Moves cleanup credential updates closer to account changes.
packages/functional-tests/tests/key-stretching-v2/recoveryKey.spec.ts	Generates registered account details for reliable teardown.

Suppressed comments (4)

packages/functional-tests/tests/settings/changeEmail.spec.ts:69

• This mutation still happens only after changePrimaryEmail's post-promotion assertions. If the promotion succeeds but either assertion fails, cleanup retains the former primary address and cannot sign in. Have the helper update the tracked credentials immediately after the promotion click, before validating the resulting UI.

      // Update which email to use for account cleanup
      credentials.email = newEmail;

packages/functional-tests/tests/settings/changeEmail.spec.ts:117

• This update is not reached when one of changePrimaryEmail's assertions fails after the address was successfully promoted. In that failure mode teardown still holds initialEmail, now a secondary address, and leaks the account. Move the tracker mutation into the helper immediately after the promotion action and before its assertions.

      // Update which email to use for account cleanup
      credentials.email = secondEmail;

packages/functional-tests/tests/settings/changeEmail.spec.ts:148

• The promotion has completed before the alert assertion, so an assertion failure here leaves the tracker pointing at secondEmail, which has become secondary. Update credentials.email immediately after confirmMfaGuard and before checking the alert so teardown remains usable when the UI assertion fails.

      // The primary email is back to the initial one, so cleanup needs it again
      credentials.email = initialEmail;

packages/functional-tests/tests/settings/changeEmail.spec.ts:188

• This assignment runs after both changePrimaryEmail's internal assertions and the additional primary-email assertion on line 185. Any of those can fail after a successful promotion, leaving cleanup on the now-secondary old address. Update the tracked email immediately after the helper's promotion click, before all result assertions.

      // Update which email to use for account cleanup
      credentials.email = newEmail;

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.