Support adopting connected applications on email change

[Will-Howard]

🧩 Summary

See this comment:

Another case I've realised is worth handling explicitly:

1. Email A applies to a course, this creates a User row as a side effect, but without any login info (no Keycloak identifier)
2. Email B signs up to the course hub
3. The account with email B later tries to change their email to email A

With the email-change flow as written (#2828, #2830), the user would get an "Email already taken" error when trying to trigger switching to the new email. This is unhelpful in the case (which is quite common) where someone applies under one email and signs up under another, or vice versa.

The main problem to solve here is what to do with any applications that use email A. Suggested solution:

• Allow the user to trigger an email change request from email B -> email A
• On the confirm screen, check if there are any applications registered against email A. If so, prompt the user to either adopt them or drop them

Reasoning:

• We already auto-link applications to the person who owns email A (on signup). By switching the email, the user is verifying that they own email A, so it's correct to allow them to adopt the applications
• It would be surprising for random applications (which may be old) to appear in your account without a prompt to accept them, so we should prompt the user somewhere (and allow them to not adopt old cruft)
• It straightforward to do this in the /confirm-email-change page, and there's lots of UI space to display it to the user

✅ Definition of done

The above design is implemented (or an alternative which achieves the same effect)

📌 Notes / Designs

No response