Properly implement a guest confirmation flow for new impersonation prevention setting

[linear]

We recently merged in a feature that allows users to enable a setting to prevent impersonation. More details here.

While working on it, it was noticed that when someone that had this setting enabled (or was part of the env variable) was added as guest, they were just filtered out and nothing else happened. They never knew about the invitation at all.

In a quick chat with @keith and further approval from @carina we agreed that this needed to change. A session with Devin was started for this here.

---

An excerpt from the session request:

(…) a few things need to happen:

1. A guest that is currently filtered out needs to be placed on some sort of pending state.
2. An email needs to be sent to this guest in order to confirm them being added as guests.
3. The email should contain a button (and link) that routes to a new api route for this.
4. The link should contain an OTP similar to the current OTP verification mechanism that are in place.
5. The API route should verify the OTP, then route depending on the result:
   1. Invalid OTP -> Client side error page that shows "Unable to verify OTP, you've not been added to the meeting.": For now nothing else.
   2. Valid OTP -> Client side success page that shows "You've been added to the meeting as a guest".
6. The API route should work whether someone is signed in or not since the OTP already takes care of ownership of the mail.
7. The API route should promote the guest from pending state to the normal flow of guests when the OTP was valid and do nothing other than routing stated in point 6. when invalid.

[linear]

CAL-6586