Your actual production database is not being touched when upgrading a staging branch.

However, odoo.sh performs an upgrade, when executed on a staging branch, in a copy of the latest, automatically created backup of production (i.e. the backup of yesterday night) always.
Note: odoo.sh (as per now) will not use a manually created database backup, neither live nor staging.

There is no option to change this behavior in odoo.sh nor can you select a specific database to run the test upgrade on.

If you want full control about what database is being upgraded you have to run the upgrade locally. For this, you can utilize Odoo's upgrade service described at https://upgrade.odoo.com/#onpremise. Here, essentially, you upload a dump of a database and in return receive the upgraded one, after a while (duration depends on the versions to cover and modules installed).

See also https://www.odoo.com/documentation/18.0/administration/upgrade.html

Furthermore it should be mentioned, that none of the above is actually necessary, when properly utilizing the Odoo upgrade utilities described here: https://www.odoo.com/documentation/18.0/developer/reference/upgrades/upgrade_utils.html
This set of tool allows you to specify how your modules are supposed to be upgraded, what migration actions are supposed to be performed - or even uninstall unwanted/obsolete modules in that process (which sounds like exactly what you should aim for).
One reason, why this is the suggested approach, is because you usually do not want to have an upgrade process that involves several manual steps that might also need to be performed in a specific order. Also, you definitely want to have a test of the upgrade on the latest possible (as is) database available to take actions according to issues that may arise while still in staging.

Alternatively (or in combination with above), as you've stated in point 2 - correct: you could just have a dummy module (original module name) in your upgrade commit (on the staging branch) that doesn't hold much more than a __manifest__.py and an (empty) __init__.py. This way, the upgrade process of odoo.sh won't complain about missing modules, even if the provided module doesn't do anything.
Note: This approach can still cause troubles, for example with records or views, that would not necessarily be removed even if not defined any longer.