I think it heavily depends on the nature and current state of the project:
All of the new (5) developers joining the team will be from similar domains and instantly grok the challenges in the features you are building. Since you understand the domain and the architecture (and the project is not too large), you can easily answer questions about it without drawn out whiteboard sessions etc. Plus the system is written very well (using TDD) and fully documented.
Over the years, the system has been has been built by several teams and each team thought they were following their best practice. This means that the code base now has several strategies for solving similar issues. Also, the project management up to now has centred around pushing out new features fast, so the technical debt has stacked up. Also, unit testing has always been an after thought. Adding to this, the domain is very niche and all the new developers will need extensive training before they will understand parts of the domain.
So, in the optimistic scenario, you probably could be coding alongside the new developers fairly quickly. The only main issue is personalities and working behaviours as the team forms into a cohesive unit. While in the pessimistic scenario, being the main link both for the domain (business) and the architecture (technical) you will be having extensive conversations and writing a lot of wiki entries or documentation.
You can probably see where this is going, something like, "Hope for the best, plan for the worst".
Having been in a similar situation in the past, I would say that you shouldn't plan on coding at all for at least 4-6 months. Taking on the responsibility for both the architecture and business link for a large project can be a lot of work (even for a team of 5). This doesn't mean that you won't be coding at all. However, the times you are coding should be interrupted frequently by people asking questions. (You might want to look into things like Pomodoro Technique etc)
Ok, now a few more things with my pessimistic hat on. :)
Your manager says it will only take 10% of your time. So, that roughly equates to 4 hours a week. If that is the case, why does your manager not just manage the project? Probably because he or she knows that it will end up taking more time then that.
As developers, IMO, we tend to severely underestimate good management. Now, SCRUM is far from perfect, but there is a reason why 2 of the 7 full time jobs go to managing (scrummaster and product owner).