I think @Neo's answer is on the right track, but I disagree with the implementation. Consider
Since I've been here, I've made a few mistakes. One of the first big ones was that when you told me to develop a test harness for the application, I didn't insist that we scope that change. At the time, I simply agreed that a test harness was a good thing and moved forward with that. That took two and a half months. Maintaining it has also cost X months.
Not realizing that mistake, when you told me to change from "live editing" to a full blown administrative panel, I repeated it. I did not insist on scoping the change. We spent another month making that change.
I can't keep making the same mistake. From now on, expect timeline updates every time a change is proposed. Here is the situation as things stand today...
Then explain how long it will take to finish your current set of tasks under the current requirements. If they are proposing new changes, explain how they will change that timeline. Also explain what happens if you do not make those changes now and instead make them later. You can even do that with changes that they've requested but that you haven't implemented.
I'm going on what you said here, so I may be missing parts of the timeline. If I am, make sure that you write those parts out for them (we don't really need to see them unless you need help talking about them).
The advantage of this approach is that it involves you taking blame. Presumably they agree that you've made mistakes, so you're starting from agreement. And it doesn't point fingers except at you. It highlights problems and eventually moves to solutions.
Don't forget to include the ongoing maintenance of the test harness in that. If that's taking up half your time, then tell them so. They can either shift work away from you (either front end or test harness) or they can live with a longer timeline.
If you don't tell them the reality of the situation, then you will continue having the same problem.
When I read this, the thing that really leaps out at me is the test harness. That's two and a half months out of a six month scope even before maintenance. That's why I said X. I don't know what X is, but it sounds like it was important. If you spent even half a month on it since then, it became the majority of your first six months and possibly the majority of your time there if it was more. You really need to quantify that.
Figure out how much time it would take to do the original project from here. Maybe with some extra bells and whistles that you've already added. You don't need to take things out. But if you didn't add anything else that wasn't in the original requirements, what would your timeline be? Then show them how any newer requirements affect that schedule. Then show them how their current suggestions would impact the schedule. You never need to say no, but tell them how much time they're adding.
They can either have Agile or Waterfall. They can't mix and match. Agile accepts changing requirements because the system always works at some level. So all requirements are either in the current sprint or they don't exist. Waterfall tries to schedule the whole project at once. That means that any time requirements change, you have to change the whole schedule. In theory the project manager should handle that, but in practice if that's not happening, then that is part of your responsibility as a contractor. You need to manage your schedule.
Also consider the possibility that some work you are currently planning on doing in the front end could be done in the back end instead. If so, you should quantify how much of your time it would take. Let the back end developer quantify how much time it would take to code in the back end. Let the manager choose where it would be better to do it. Even if it takes longer in the back end, it still may make sense to do it there if you are further behind and the back end developer is currently waiting on you.
It's possible that the back end developer should take over the test harness. If there's only two developers and it's taking too much of your time, there aren't many other options. And you would be far better off if you could focus on your original project. If the backend developer has been waiting on you, then this gives work to do in the meantime.