Client needs to cleanup after user revoked access

[tyler-dane]

Where did this happen?

Local code with an up-to-date main branch, Hosted (app.compasscalendar.com)

Expected Behavior

Command Palette: After a user revokes access to their Google account, Compass removes their Google data and notifies the client over websockets. When the user then opens the command palette, they should see the 'Connect Google Calendar' option.

Creating events after revoking: After a user revokes access to Google, they are still allowed to use Compass like normal. However, their events are saved to indexeddb (just like they were before they originally connected their gcal)

Current Behavior

Command Palette: After a user revokes access to their Google account, Compass removes their Google data and notifies the client over WebSockets. When the user then opens the command palette, they see 'Google Calendar Connected' in the command palette.

Creating events after revoking: After a user revokes access to Google and they try creating a new event, they see an alert and console message:

Alert: AxiosError: Request failed with status code 400

// 400 response
// POST {endpoint}/event

{
    "result": "User has not connected Google Calendar",
    "message": "User is missing a Google refresh token"
}

Steps to Reproduce

1. Connect Google Calendar account
2. Remove Google calendar access
3. Make a change in Google Calendar, which'll trigger a webhook to Compass
4. Compass will recognize that the user revoked access, clean its data, and notify the client
5. The client will see a toast notifying them that their google data was removed
6. Create a new event in Compass.
7. See alert

Possible Solution

Happy-path: Prevent this scenario from happening by updating the client state/store immediately after getting a notification about Google revocation.
This won't work in every scenario, though. For example, the user might not have Compass open when they revoke, so the client won't receive the notification right away.
In this case, we need to update the frontend's error parsing in the API client to handle when receiving a 400 error with the message about the user revoking access.

Context

Follow-up to #1478