Hello @Dhargett
Without SIP dialog will be hard to identify the cause, but maybe could be a UPDATE message issue where MSFT Teams are not processing after picking from park, so it will not reopen the channel keep the call "on hold".
As soon as PARK by default send messages notifying that call are putting on hold maybe a solution for that are not notifying MSFT Teams that call are on hold (but keeping MoH, of course).
You can do that by blocking sending update messages on specific dial-peers.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-edupdate-block.html#task_6F344CFF9156472597C140063A081B74
Other way are to enable on CUCM Duplex streaming to prevent "closing channels" when call are putting on hold.
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/212640-troubleshoot-music-on-hold-failure-when.html
To really know what are happening the best way it should analyze: SIP Dialog from CUBE, Callmanager logs from CUCM, Any SIP Dialog from MSFT Teams.
Hoping that's be helpful.