Better to say that it's the demo version, because that's what it's only good for, If you really want to lose the client's confidence, deliver the product as-is, let the client find out about the bugs the hard way, and put some lives at risk. I will tell you that would be extremely uncool and if you were in the US, you'd be exposing your employer to a major lawsuit if anything tragic happened and it can be traced back to your product.
Major software firms such as Microsoft routinely blow out their ship dates. Microsoft probably regained a lot of credibility over the years for shipping reliable products late than shipping defective products earlier. I am fairly sure that you are not the only PM even in your firm who has been faced with this situation. Yes, read the answers to your post but also consult the more experienced PMs about how they handled such a situation, because there may be a policy or some kind of consensus in place on how to handle such a situation.
You shouldn't blame yourself for the code that broke. You did not write the code in the first place. Instead, you should ask yourself how these bugs slipped past the developers. Was it inadequate testing? Did the developers know about the bugs but didn't tell you? As a PM, you are totally dependent on the developers being candid with you. And being fully competent. Eventually, you'll need to get to the bottom of how these failures happen. That's your job.
I suggest that you tell the client that you have a few hiccups with the software, that these hiccups were last-minute and that you're having your people fix them, you are also having them scrub the software thoroughly for any others issues. You could say that were were planning the beta version i.e. client-ready of the software but because of these newly discovered hiccups, the version remains at version alpha i.e. in-house for now. Fact is, some bugs show up only when the whole app is put together or only when some modules interact with others. Give them a revised deliverable date but advise them that while you are confident that it will be met, the reliability of the software comes first.
It's an unfortunate event but it would have a silver lining if you took the event as an opportunity to gain and keep the confidence of the customer by being forthcoming and not being afraid of delivering bad news and by your unwavering, uncompromising focus on reliability. And yes, if they ask you who is responsible for this, deflect their question by saying something else, like "I am the PM. I am in charge. I am taking responsibility for this whole thing". Hopefully, they'll like you all the more for it. Basically, what you want to communicate to them is that something went wrong but the project remains in good hands.
Follow-up comment from @JoeStrazzere "You could also share the bug list with the customer, and engage them in the decision about demo versus production. Some bugs have workarounds, some do not."