A few ways to handle this. I generally think of each app / dashboard as an application, and Connect allows reverting to previous versions / etc. You can also use "vanity URLs" to abstract away a specific application endpoint from the URL (moving that vanity URL to a new piece of content, after testing, can become the new "live" version).
The problem we/you really need to test is - what does yum upgrade do to already built R packages. From yum upgrade's perspective, you are definitely affecting the whole Connect server, but I am hopeful that there will be some level of protection in the way packages are compiled/upgraded and that you will only need to worry about backwards incompatibilities in the system libraries (which are hopefully few/far between).
This sounds like you are interested in learning how Connect chooses an R version? The short answer is that it generally tries to match R version as closely as it can to the one used in development. The longer answer is that you are in control, and it can be configured as you like (depending on the R versions that you make available).
I definitely am interested to see what happens to R packages when the underlying dependency is upgraded. I'm also curious if your org could run the yum upgrade on RStudio Server Pro first, so at least you have some runway to debug issues before deploying those same library changes to RStudio Connect. As @kellobri suggested, maybe some type of configuration management (Ansible, Puppet, Chef, Terraform, etc.) will help keep the boxes in sync so your RSP server becomes your "staging" server of sorts.