Let's start with the process by which you estimate how long it takes to do your work. Always estimate time for documentation and meetings and email communications. Now for future projects you won't run out of time to do those things. Also assume only 6 hours per day per person when figuring out the end date for delivery (there is always indirect work such as required HR meetings and vacation, etc. to account for, you can never plan for anyone to be on a project 40 hours a week or you will miss every deadline and never have time to do documentation). These are the two most common reasons why I have seen people run out of time.
To my mind what is critical for you to update on this last project are the bugs you fixed that did not meet the spec. Personally your manager failed there as he should never have allowed that to happen, particularly if the customers (and internal users are also customers) were not informed beforehand. There may be a good reason from a user perspective for that requirement that you threw out because it was easier to fix the bug if you ignored the requirement. They may now be expecting behavior they are not going to get. That is a failure of your entire development staff that you allow such actions to happen.
One reason this needs updating is for maintenance. Sooner or later someone new will come along to fix something that was changed without documentation and will think that the failure to follow the spec was a bug, not a deliberate action and will change it back to follow the spec.
Or the users will complain that it doesn't do X which was in the spec and you won't have any proof that X was changed because Y bug caused X to be reevaluated as a requirement. Having been in a few of these argumnents in the past, I can tell you they aren't pretty whether they are internal or external customers. The less agreement you got for these changes before you did them, the more likely they are to rise up and bite your development staff later. And six months from now you won't remember why you did it that way either. It's no fun to explain why you did something when you have no idea why you did it.
Additional features aren't as critical, but should probably at least be listed even if you don't have the time to do a complete description.
You need to make these changes now when they are fresh. Convince your manager to let you spend a day or even half a day doing this. Or sneak in a half-hour every day for the next couple of weeks if you have to in order to document the most critical deviations.