In scrum, do you reserve any extra story points for tasks that weren't part of the original estimate, but my come in between the sprint like any technical dependencies?
In Scrum, "all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases" are part of the Product Backlog. It's generally up to the team on how to organize them and what constitutes separate Product Backlog Items versus what's wrapped up in one representation of a Product Backlog Item. Your tooling for managing the Product Backlog will likely drive, to some extent, how you manage dependencies between Product Backlog Items or what types of work are group together. Often (although not specifically called out in the Scrum Guide), the INVEST criteria is used to determine a good scope for Product Backlog Items.
All Product Backlog Items have an estimate. However, the Scrum Guide doesn't elaborate on what is required for an estimate. Although Story Points could be used, using hours is also allowed. Some teams may not explicitly estimate and strive to obtain Product Backlog Items that are all approximately the same size. The purpose of the estimate is to provide guidance for the team to take a Product Backlog Item and determine if it is feasible to complete within the Sprint, with the other Product Backlog Items selected for the Sprint.
So, no - in Scrum, you do not "reserve" Story Points (if you are using Story Points to estimate Product Backlog Items). Each Product Backlog Item's estimate should include all of the work needed to get that Product Backlog Item to a Done state, per the team's Definition of Done and the conversations and criteria around the Product Backlog Item.
In our organization we reserve 20% of the sprint's capacity during sprint planning for unplanned work. This is because our teams also do L3 support work, so if something cannot wait for the usual process of creating an item on the Product Backlog and moved into some future sprint, we can handle it in the current sprint.
As nice as it would be to never have sprint work impacted in this way, the reality is, we have customers and we'd like to continue to have them. If this mission critical software has an issue that can't wait, it can't wait. These changes are discussed with the team, the scrum master and the product owner before accepted into the sprint. To the extent possible, issues are pushed out to at least the next sprint.
If nothing comes up, as is often the case, we'll pull in work from the backlog as stretch goals.
Note that I used the term capacity rather than points. It may seem pedantic, but in Scrum it's important to move away from thinking of points as based in time and instead think of them as based in complexity.