Currently, chatMode is a pure function of the URL. This is however inconsistent with how activeChatThreadID works, which will stick around based on the previous value of navInfo when the value cannot be determined based on the URL.
This inconsistency leads the bug described in ENG-2824. In that case, the activeChatThreadID stays around when the user switches to the calendar and back, but the chatMode gets reset, which leads to unexpected behavior.
To address this, I think we should make chatMode and activeChatThreadID consistent. In this diff, I took the approach of making them both "sticky".
We could also consider resetting activeChatThreadID at the same time we reset chatMode, so the user would have to reopen the chat creation flow after going to the calendar and back. I figured my approach was a better product experience, though.