There are a few ways to deal with this, but you haven't indicated if your application is web-based or a desktop application. From the description, I am going to assume it's web-based. You also fail to mention the industry your application is intended for and should be considered as part of the solution. If your application is based in a sector that is covered by some regulations, you may not be able to store all customer data in a single database and may need to separate clients into physical databases with a centralized database for authentication; this can be a problem with some products containing financial or health care information.
In general, I would have a table that contains the person's email address (username) and authentication details such as password hashes or account IDs for logging in with MS, Google, or other provider accounts, and a table that has the user ID with a list of tenant associations. I would have a table for user preferences that would contain the "default" or "last" tenant the user interacted with, and load the data from that tenant. I would have a session token stored in a cookie and the current tenant the user is interacting with stored in a session table, with that Tenant ID stored in there. The session token becomes the glue between the client and the server backend. If the user wants to change tenants, they can select the one they want to work from a menu on your end, and the current tenant gets changed in the server-side session data. This is more or less your option #5, but it takes into account other considerations. What this does mean is that it is important that an administrator is not able to change a user's password, which is not a bad thing. If a user can change a password, then it would make other tenants' data (tenants that may not be related to each other) visible to an admin. But in either case, there should 100% be MFA, which should, in theory, prevent that from happening.
For multitenant applications, I would avoid using sequential IDs and use UUID or GUID values for primary keys. This makes it much easier to merge data across multiple databases or production/staging environments. Suppose you are dealing with a sector that has strict rules about mixing tenant data. In that case, GUID keys in the DB are the way to go, because if there is a merger, then merging the data means it can just be copied to the new table without conflict, and references to cross-table data will not have to be changed.
In generally today, I would probably avoid storing user credentials all together, i.e password hashes and use integration with the popular providers such as Facebook, Google, Microsoft, etc. It removes the responsibility of dealing with password changes from your application and in the end more likely makes it easier on the users in the end as they have fewer accounts to deal with. In the enterprise space we are starting to remove all credential storage and rely on these mechanisms.
I would avoid option 1 as that is a nightmare to get people to remember company names and the variation that might have been used the person doing the setup or after company name changes, etc and the retraining involved after the fact. Option 2 is one to be avoided in our experience as users can mess up the query string not realizing where there cursor is or enabling unforeseen vunlarbilities into the app. Option 3 requires integration into things outside the app itself such as a reverse proxy server or something process the domain name. Option 4 is also a nightmare for reasons you pointed out and others, which leads to option 5 as you identified and and I expanded upon.
Although I didn't provide an alternate means I hope that some additional thoughts were provided in option 5 which is likely the best and most flexible routes and prevents the user from having to sign in and out to switch tenants.
Jeremy