If hashing should occur server-side, how do you protect the plaintext in transit?

It's my understanding that the most widely used method is to hash and salt the password server side and to rely on TLS/SSL to protect the password in transit.

This is entirely correct.

The main question that remains unanswered to me is what if TLS/SSL is breached?

Then you are in a lot of trouble, and nothing else much matters.

In the context of the hostile network you're describing, reading your password is the least of your worries. They can see everything you see, and they can read everything you write. They can inject arbitrary content into any page you request in a browser. If TLS/SSL is breached by a MITM, nothing can save you, as the fundamental foundation of all other security is gone.

Trying to perform hashing on the client doesn't matter, if the MITM injects a keylogger that reads the password as you type it.

Many companies, schools, and government agencies that provide network services on site have provisioning profiles or other systems in place to allow them to decrypt network traffic on their own network.

They cannot decrypt traffic simply by virtue of it passing through their network. Typically they install a root certificate they own, and then MITM your TLS traffic and replace the certificate of the site you're trying to reach with their own certificate. When you try to establish a secure connection with example.com, you're actually establishing a connection with the MITM, using their cert, then the MITM establishes their own secure connection on your behalf to example.com. When you send something to example.com, you're actually sending it to the MITM, who decrypts it and then forwards it over their own secure channel to example.com.

Wouldn't this mean that these institutions could potentially view the plaintext version of passwords over their networks? How do you prevent this?

Again, only if you install their root certificate, and then intercepting passwords should be he least of your worries. You should never log in to any personal accounts on these devices, as you have no privacy, and as you say, all of your traffic can be read by the business.

As you have seen, the general consensus is that you need to salt and hash server side, and send everything over TLS. While you can do hashing or encryption on the client side, it does not protect against the threats you are concerned about.

Many companies, schools, and government agencies that provide network services on site have provisioning profiles or other systems in place to allow them to decrypt network traffic on their own network.

Assuming you mean that the user has installed and trusted the root CA, yes. TLS isn't decrypted, but terminated by the proxy.

... these institutions could potentially view the plaintext version of passwords over their networks? How do you prevent this?

Imagine you are using the most secure cryptography to encrypt the password on the client side before it is sent to the server. However, you cannot forget that a TLS intercepting proxy can do far more than just view contents of TLS traffic; it can also modify things. To defeat your strong crypto, all the proxy has to do is inject a basic JavaScript keylogger into every page that will steal the password as it is being typed. Or in a corporate setting, the computer could be logging keystrokes already.

So, it's fairly safe to say that securing web browser traffic from a TLS proxy is pretty futile.

So what's the solution? At least for myself, I would never enter a password into a site if I know the traffic is being intercepted. Further, I do not log into sites on computers I do not own and trust.

From a design perspective, if it is absolutely unacceptable that a password is ever visible to a TLS proxy, you could instead create a native application that enforces certificate pinning and/or communicates with the server using asymmetric keys hardcoded into the app.