Reach frontend and deployed contract info: fixed binding or dynamic resolution for rollback after a failed redeploy

We deploy a Reach DApp to an Ethereum-compatible connector, where contracts are immutable, so any upgrade means compiling a new artifact and redeploying rather than patching in place. Our frontend currently hardcodes the published contract info (address) from the most recent deployment.

After a redeploy produces a broken or unexpected artifact, we want the frontend to roll back by repointing to the prior deployment without shipping new code. That raises an integration-boundary decision: should the frontend bind to a fixed contract info value baked in at build time, or resolve contract info dynamically from configuration or a registry at runtime? A fixed binding makes rollback a redeploy of the frontend; dynamic resolution makes it a config change, but adds a trust and consistency question about who can update the pointer.

There is also a versioning constraint: artifacts compiled under different Reach stdlib versions may not interoperate, so any rollback target must have been built with a compatible stdlib.

Which binding strategy do Reach-based frontends typically use so that rollback after a failed redeploy is a configuration change rather than a code change? How should stdlib version compatibility between the old and new artifacts be checked before repointing? On connectors that permit in-place application updates (e.g., Algorand), does the same decision still apply?