My first suggestion would be to fix your terminology to improve communication, both internally and externally. You are using terms like "Scrum Master", "Sprint", and "Sprint Review". These are terms from Scrum. Scrum is a well-defined process framework with specific roles, responsibilities, events - it has rules and those rules are defined in the Scrum Guide. If you aren't using Scrum, you shouldn't be calling what you do Scrum and you shouldn't use the Scrum terms, since it only confuses people. Do note - it's perfectly OK to not use Scrum, or to take the good ideas from Scrum (or any other process framework or methodology) and build your own process.
Next, I'd look at your method of estimation. Going back to terminology, I would recommend that you stop calling what you are doing "story points". Like Scrum, there are commonly accepted definitions of "story points", and it's not a fixed amount of time. That said, if time estimates are working for you or you have a reason that you must use them, you should continue to use them.
When planning an iteration, I would consider three things. First, consider total team capacity. If you have specialists, work on cross-training so there's little work that must be done by a single person to enable full-team capacity estimation. When estimating, don't consider that the work will be done by an expert but an average member of the team. If the expert gets it, maybe it'll get done faster. If someone else gets it, you'll be more likely to get close to your estimate. Finally, never plan at 100% capacity. There's always overhead - vacation, unexpected leave, meetings. I'd have to find my sources, but the most productive organizations reach about 80% (using your estimation scheme, that is 4 "story points" per week of iteration per person, assuming no planned vacation or holidays) and many organizations are closer to 60-70% (3 "points" per week of iteration per person). Since a common rule of thumb is that all work should be able to be complete in an iteration, a single unit of work should be no more than 6 "points" in a two week sprint (that accounts for a capacity of about 65% per person - a pretty average organization). Be sure to consider leaving some of your capacity for production issues when planning as well - you can use historical data to figure this out.
For tracking metrics, it really doesn't matter what you do as long as you are consistent. If you don't estimate production issues, you will likely see a pause in burndown as one or more people stop working on estimated, planned issues and work on production issues. If you do estimate production issues, your remaining work will increase and then burndown as work progresses. In either case, I would not update the planned burndown line. My personal preference is to estimate nearly all work - new functionality, modified functionality, bugs against production. The only thing I don't estimate is if work needs to be redone (as an example - work is finished in development but bugs are found by an independent tester - even if those bugs are logged in a tracking system, I would not estimate them unless the bugs were released to production). I would also recommend not giving a default value for production issues, but having the team attempt to come up with a reasonable estimate for each and every one.
For reestimating, again, it doesn't matter as long as you are consistent. My recommendation is to never reestimate. If work was not completed in one iteration, it retains its original estimate for the purposes of planning the next iteration. It's common in project management to only award "credit" for completion to done tasks. In some cases, a small percentage is awarded for started tasks. It's often incredibly difficult to tell how much actual progress has been made - if you think you have a fix, testing could reveal that another problem was introduced.
At the end of every iteration, you should be holding two types of events. The first, what Scrum calls a "Sprint Review" is product or service focused. You look at what you've accomplished with key stakeholders and discuss not only what you accomplished in the iteration, but what your next goals should be for the next iteration. The second is an internal reflection on how the team is working to find ways of improving the interactions between the team and stakeholders, between members of the team, or ways to improve the way of working (the processes, methods, and tools the team uses).
I would also start looking into why you can't change things like having one of the developers play the role of a facilitator and coach or why you must estimate in time rather than some other unit. I would highly recommend that most organizations have someone dedicated to understanding and improving processes, methods, and practices of engineering teams. This person should understand the environment in which the team and organization operates and various methods and can coach both the organization and the team on a path of continuous process improvement.
