Failing project, how can I pull it back?

What have I missed and is there anything I could try to see if I can help save this project?

Did you make it clear that Scrum consists of a series of "very tight deadlines", known as Sprints, each one of which is the most important project that can be had?

The Sprint is the project that allows empirical process control to be established and maintained. The leap-of-faith being taken in the project you describe is comparatively hair-raising and the consequences are as you see them.

I'd suggest that in reality you have a succession of fake sprints, few of which result in Done work for inspection and adaptation, and which are effectively go-faster stripes on a waterfall process.

We have been working in sprints but I think you're right with the suggestion that ultimately, they are 'fake sprints'. We work with 2-week sprints and have a goal with what should be a working iteration at the end, but often this is broken, many times right at the end of the sprint by a messy commit. Or people get diverted (by the head) onto 'critical issues' that aren't that critical. So quite often the goal isn't achieved. Any suggestions on what I could do to improve this?

Find out who in senior leadership actually wants the situation to be improved, so they can create, communicate, and reinforce a sense of urgency for change. Who actually wants to establish empirical control over value, flow, and quality within Sprint timescales?

The organization must clearly stop doing things so it can start doing Scrum. There is an organizational gravity to be overcome, and it doesn't sound as though you can create the requisite sense of urgency for this by yourself.

I'm going to be very blunt in this response.  My opinion is that you have done everything you possibly can.  @Ian suggests that someone in senior leadership could be your partner in improving the situation. However, from what you have said the "head" would not listen and doesn't seem to think there is a problem. 

Sometimes the best way for people to realize that they are wrong is to suffer some pain.  The "head" needs to realize that his expectations and practices are unreasonable.  You can show that you have done everything that you can to make this work.  They need to realize that they did a lot to make sure it wouldn't work. There is nothing that a Scrum Master can do to solve this problem.  You do not have magical powers and nothing short of a miracle would fix the problem you described in time to deliver the product in a few more fake sprints. 

I know this isn't the response you had hoped to get but I don't know how to give you one that is pleasant.  However, I will say that you have a very good opportunity to help everyone learn about empiricism.  Empiricism says that all learning comes from experience.  You do something, inspect the results, learn, and adapt as necessary.  The situation you describe is full of opportunities to inspect, learn, adapt.  Your project may not end in the desired manner but it isn't a failure if you learn from what happened and adapt so that you are able to avoid the same situation in the future.  

Thank you both so much for your responses. I really appreciate them!

So many great points from Ian and Daniel.

To add to this…you can lead the head to water, but you can’t force them to drink. Don’t feel like you are at fault for this, you are doing what you can to lead and guide. 

Some thoughts, and other things you could consider trying…

In order for Adaptation (change) to occur, you need Inspection. In order for Inspection to be effective, you need Transparency. Transparency means making things visible, and understandable to those viewing it. If the Head is not seeing what you are trying to show them, you may need to approach it in different ways. Speak their language, catch their attention, find something that connects for them. Light a bonfire if you have to.

How might you hold up a mirror in the situation to help with this?

What can you make transparent so the head and leadership can see the current situation more clearly, and understand the cause and effect impacts of activities like adding new scope to the Product Goal or injection of ‘critical issues’? (When you do this, this happens…)

What data do you have available that can be leveraged for this?

If you have Done work, you could look at the team’s throughput each Sprint to get a sense of how much work can be done in each iteration. This won’t be perfect, but it can be a way to illustrate that there is a finite amount of work that can be completed in each Sprint, and as such each Product Backlog Item and Sprint Goal needs to be carefully selected. Trade offs are going to need to be made as there is no room for waste or nice to haves.

If you have refined PBIs in the backlog, your throughput can be compared against this to illustrate how many Sprints may be needed to complete what is known today. (This project car has this much gas left in the gas tank. You can’t reach every destination with the fuel/time you have. Where do you want to drive with your remaining fuel?)

If you have quality issues, how might you quantify and illustrate this? Can you tie back to injection of ‘critical issues’?

You mentioned stability issues. Is Technical Debt being made transparent in the Product Backlog?

What else might you leverage to shine a spotlight and bring Transparency?

Thoughts on this?

A tiny bit late (!!) but thank you Ryan! I did read/absorb this at the time and found it very helpful, I then completely spaced on replying! 
I was very grateful for all the replies and took the advice on board and worked it into my approach. Unfortunately, it made no difference and I ended up handing in my notice. Nothing changed under the person who took over from me either - I found out they only stayed a few months before also leaving. A bad situation but a good learning experience.