In a word - contingency.
Contingency is the amount you add for "other stuff" - the things you can't account for elsewhere in your estimate. Does SMc cover it in Software Estimating? I can't remember and my copy is at work (I'm on holiday answering this - how sad am I)...
Anyway, generally speaking there are three sorts of contingency I'd recommend looking at:
1) Risk specific contingency - that is where you identify a specific risk and add a certain amount of time to cover the potential overrun related to it. The first thing to be clear on here is what a risk is - it is something which may come to pass, which will negatively impact on the project, which is outside of your control.
This last part is critical - it's not just "things taking a bit longer than I thought", it's "the 3rd party scheduling module we've been told we have to use as it's a company standard might not be up to the task". The way you calculate how much risk contingency to add is the percentage chance the risk might come to pass expressed as a decimal (so 50% = 0.5), times the impact of that risk (so in the example say you need to manually write CRON jobs instead of using the scheduler and this will take 10 days, this number is 10 days).
So if there's a 50% chance of your risk coming to pass, and it will take 10 days effort to get round it if it does, you add 5 days. Add up all the values for all identified risks on the project and add it to the total.
2) Shit Happens Contingency - The best description I ever heard for it, even if it's not elegant. It's an IT project, shit happens. It never goes how you think it will, things take longer, get missed out and so on. Generally SH Contingency will be between 10% (absolute minimum) and 25% (though can be higher) with 15% being about typical, the exact level dependent on the level of uncertainty and general risk (moving goal posts, uncertain requirements and so on).
If your PM doesn't accept SH Contingency (and it's possible, he might have no experience of IT projects or be a blind optimist), then just add it to all the individual amounts. If he knows what he's doing he'll have a risk log of his own and love you for thinking about this stuff. Certainly if he has any sort of PM qualification (such as PRINCE2) he'll know about it.
3) Change Contingency - This is where you are fairly sure that the client will raise changes but don't want it to be a point of contention. Add either X days or X% and it goes into a pot for changes the customer raises. There are two ways of dealing with it: either you tell them about it and it's theirs to spend or you don't tell them about it.
The first way is best but needs a fairly educated and fair minded customer - things are classified as changes and he can spend his pot as he sees fit (based on you estimating things as they come up).
The second way you mention that it's a change but don't look to charge him extra. You do have to note all the things that you spend it on so if it does get to the point that it runs out and you have to go back to the customer and ask for more time or money and they say "hold on, I'm paying blah blah blah" you can point out all the things they've already changed which you haven't charged for as a sign that you're not being entirely unreasonable. It doesn't always work but it almost always strengthens your hand in the discussions.
None of those three specifically cover things you've forgotten but I think between them you'll fill a lot of the gaps you've got.