This depends wildly on the situation, the bug, the customer, and the company. There is always a trade-off to consider between correcting the implementation and potentially introducing new bugs.

If I were to give a general guideline to determining what to do, I think it'd go something like this:

1. Log the defect in tracking system of choice. Discuss with management/coworkers if needed.
2. If it's a defect with potentially dire consequences (e.g. your example #2), run, scream, jump up and down till someone with authority notices and determine an appropriate course of action that will mitigate the risks associated with the bug fix. This may push your release date back, save lives, wash your windows, etc.
3. If it's a non-breaking defect, or a workaround exists, evaluate whether the risk of fixing it outweighs the benefit of the fix. In some situations it'll be better to wait for the customer to bring it up, since then you know you aren't spending time fixing/retesting things when it's not 100% required.

Mind you, this only applies when you're close to a release. If you're in full development mode, I'd just log the defect so it can be tracked, fix it, and call it done. If it's something that takes more than, say, half an hour to fix and verify, I'd go to the manager/team lead and see whether or not the defect should be fit into the current release cycle or scheduled for a later time.

I'm not a lawyer. It sounds like you already have one for the purposes of suing your client; while you have him or her on retainer I would recommend getting their advice on this.

There are some other questions on this site that deal with "kill switches" and other ways to disable software for which the developer has not received compensation. It is usually considered a bad idea to simply build one in to "turnkey" software (where you will develop it and then transfer full rights to the client), without the contract having stipulated this possibility.

First off, if your contract does not specifically state that you can disable the software for non-payment, or that the client does not have any rights to the software until payment is received in full, then you cannot flip any "kill switch" without being in breach of contract. Absent any words to the contrary, "possession is nine-tenths of the law", so it's his software once he is given possession, and to destroy it would be akin to dynamiting a new office building you'd built for him if he didn't pay for it.

The second point follows; any contract you offer to any client should have a clause to the effect of: "Intellectual property transfers on satisfaction of contract". That means that even if you have given him a copy of the software to use, until he's paid you in full, he doesn't own it. This WOULD give you the right to disable his or any copy of the software for any reason until full payment has been received, because it's still yours and you can do as you please. Now, he's breached the contract, and you haven't, so the case is MUCH easier for your lawyer to present, and meanwhile your client doesn't get any benefit from his ill-gotten goods.

The analogy to a building contractor holds: once a building under construction is able to be secured against unlawful entry, it is, and the contractor will generally keep all copies of all keys to the premises until the work is complete and signed off on, and payment received in full. Even after the keys are handed over, if payment falls through he can attach a lien on the property and in the extreme have it repossessed. The same holds true here; you may give the client a key to get into the software, but you hold the "master" key, and he doesn't get administrative access until you're paid in full. If he can get in now, and doesn't pay you, you can just "change the locks" and lock him out of the software.

However, you have given your client the "master" key to the software, and he's gone and changed all the locks so now YOU can't get in. That's not the way it should work. You can still claim damages, but in the meantime your crooked client can use the software, copy it elsewhere (that's a big thing that can't happen to a contractor; if he takes his building back he doesn't have to worry that you've made an exact free copy on another lot), etc etc. Basically, your only remedy is to enforce payment in full, because you cannot guarantee that you have reclaimed all copies of the software. You probably wouldn't be happy getting your software back even if you could guarantee he had no further copies; it's likely custom work you can't just turn around and sell to someone else.

Understand that regardless of your rights to the software, his data belongs to him. You cannot touch it. You can stop his access to the software that you built, but if you destroy his data, that's like burning his possessions after repoing the building you built him that he didn't pay for. You have no right whatsoever to that data, and must either leave it in place on his computer intact, or if the data cannot be accessed in a reasonable manner without your software, you must remove it from the entanglement with your software and give it to him in a useable format (such as a human-consumable database, or printed or electronic copies).