If I understand correctly, you have 6 developers and 4 testers (I'm excluding the automation engineer because they aren't doing work in the sprint from your description). You say that the developers are completing pieces of functionality in as short as a day, so some work should getting tested early on. It is also clear that regression eats up a lot of time at the end of the sprint. These bottlenecks happen because you have people tied to tasks and there are, generally, two ways we can approach this (or a combination of both): spread the load and re-order the tasks.
Reorder the Tasks
The team could experiment with a form of test-first development. Behavior-Driven Development and Test-Driven Development (the two are best used together) are the most common approaches to this, but not the only ones. In it, you write tests for functionality before you write the code and then you write the code to fulfill the tests. This is ideally done in an emergent way (rather than writing all tests first) so this means that the tester would help the developer identify the main test case, then the developer would code to it. Then they would create the next test case - either for expanded functionality or for negative and edge cases. This way it becomes a collaborative process, rather than a staged one. Technically, both of these practices require the creation of automated tests, but I've seen teams have some initial success even without automation.
One side effect of this is that a lot of tests move closer to the code under test. Decision-logic testing moves to the unit test level, integration tests are still a different thing than unit tests, but a lot of times they use the same tools. This means your testers will be looking at code more, but most are used to it in a few days and the developer is right there with them to help explain. In the end, this results in a much more sustainable test suite.
Spreading the Load
There are a number of places in your description that you could spread out work. First and probably easiest is asking developers to help with the regression. Certainly, testers and developers have different skills and I'm not of the opinion that a developer can do all the testing, but regression is usually following scripts - let the developers take some of that work.
Next, if you try test-first development, you may find that it's easy enough for the developers to hook up the framework to allow the test steps to run automatically while they are writing the code. Doing this with the input of the automation engineer will have huge payoffs. Most developers don't write code that is easy to integrate automate testing into, but doing so isn't hard or significantly more work if you know what you are being asked to automate.
Finally, about half of the code you write in test automation can be learned in a few days. After that the learning curve gets very difficult. Testers can use some of their light time pairing with the automation engineer or developers to start building those skills (or get an expert in to do a workshop to train them). 4 testers and 6 developers can create new features way faster than 1 automation engineer can automate them. Most teams I see who set this on one person quickly bury them with a pile so deep they eventually give up.
There is a lot that can be done. Staged development with rigidly-defined roles is a very efficient way of working, but it doesn't scale down well. When developing in short increments, you are purposefully trading out some of that efficiency in exchange for working software that you can quickly put in front of the user and make sure you're building the right thing in their eyes. To get this, you need to lose the rigid structures.