fix(emulator): don't clear email when unlinking password provider

[swseverance]

Unlinking the password provider was incorrectly clearing email, emailVerified, and emailLinkSignin. This caused users to display in the auth dashboard without an email. The behaviour also differed from prod firebase behavior in that it was possible to sign a user up, unlink the password provider, and then sign the user up again using the same email address. In prod this generates a 400 response.

Resolves #10517

Description

Fixing a bug in the auth emulator described above

Scenarios Tested

In prod firebase:

1. perform auth.createUserWithEmailAndPassword(email, password)
2. perform user.unlink("password")
3. perform auth.createUserWithEmailAndPassword(email, password) (with same email as step 1).
4. Observe the following response from POST https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=AIzaSyAg1sZIrP8lzPUUHcevdLzscVDbnVtQl8k

{
  "error": {
    "code": 400,
    "message": "EMAIL_EXISTS",
    "errors": [
      {
        "message": "EMAIL_EXISTS",
        "domain": "global",
        "reason": "invalid"
      }
    ]
  }
}

In local firebase (on this branch):

1. perform auth.createUserWithEmailAndPassword(email, password)
2. perform user.unlink("password")
3. perform auth.createUserWithEmailAndPassword(email, password) (with same email as step 1).
4. Observe the following response from POST http://localhost:9099/identitytoolkit.googleapis.com/v1/accounts:signUp?key=AIzaSyAg1sZIrP8lzPUUHcevdLzscVDbnVtQl8k

{
  "error": {
    "code": 400,
    "message": "EMAIL_EXISTS",
    "errors": [
      {
        "message": "EMAIL_EXISTS",
        "reason": "invalid",
        "domain": "global"
      }
    ]
  }
}

The behavior of the emulator now aligns with production firebase. Previously the emulator would allow you to sign a user up with email and password, unlink the password provider, then sign a user up with email and password using the same email as before.

Sample Commands

N/A

[gemini-code-assist]

Code Review

This pull request modifies the Auth emulator to ensure that email-related information, including the email address, verification status, and email link sign-in preference, is retained when the password provider is deleted. Previously, these fields were explicitly cleared during the provider removal process. A new test case has been added to verify that an account's email remains registered and unavailable for new sign-ups after the password attribute is removed. I have no feedback to provide as there were no review comments to evaluate.