Considering your project has a "php": ">=7.2" requirement, upgrading to 8.2 shouldn't break anything since it's within it's constraints. Also, any damage done to the installed packages can be undone by removing the vendor folder and running composer install again.

That being said, what I would suggest from a production standpoint is:

1. What I used to do in the past is have multiple php versions locally:
   The one you use to run composer update/install on the project which is 7.2 in your case and run it with /usr/bin/php72 $(which composer) update or whichever dir you installed the php version required for composer.
   And then the other php version (8.2) php-scoper /usr/bin/php82 php-scoper.phar add-prefix ....
   This way both project/composer and php-scoper run on the required php versions.

2. The other way, and the way I am doing it now is locking the platform's php version by editing my project's composer.json and adding the following section:

{
  ....
  "config": {
    "platform": {
      "php": "7.2.34"
    }
  },
}

This way, I can run a single php version (8.2) but composer will always require packages versions compatible with the specified php version (7.2 in this case), because he thinks I am using the specified version.